DM6446 - the write performance of SD card is dismal

We have a similar issue on our DM6446 board.  The test result is even worse (about 10KB/s):

/ # dd if=/dev/zero of=zero bs=320K count=1 oflag=sync
1+0 records in
1+0 records out
327680 bytes (328 kB) copied, 30.1853 seconds, 10.9 kB/s

It is pretty fast to copy a big file to the file system on SD card, but extremely slow when umount it.  Does any one have similar experience?  And any solution?

Hi,

Have you tried using the latest community based MMC/SD driver?

Regards, Sudhakar

Thanks for the reply.  The problem is, there is no previewer driver in the latest PSP, so we are stuck in DVSDK 2.00.

http://e2e.ti.com/support/embedded/f/354/p/111126/432343.aspx

By the way, I just tried it on PSP 3.01 and the writing speed is about 1MB/s on same board and same SD card.  Thanks.

Hi George & David,

Are you still facing this problem? If you are using CFQ IO scheduler algorithm, please try to use a different one like "noop" or "deadline". This will solve the problem. If you are particular about using CFQ, please make the slice_idle parameter of CFQ to '0'. This will also help.

-Renjith

www.pathpartnertech.com

Thanks for your suggestion, Renjith.  Unfortunately it didn't solve the problem.  Here is the result using "deadline":

/ # dmesg | grep "io scheduler"
io scheduler noop registered
io scheduler deadline registered (default)
/ # dd if=/dev/zero of=zero bs=320K count=1 oflag=sync
1+0 records in
1+0 records out
327680 bytes (328 kB) copied, 38.2448 seconds, 8.6 kB/s

And here is the result using "noop":

/ # dmesg|grep "io scheduler"
io scheduler noop registered (default)
/ # dd if=/dev/zero of=zero bs=320K count=1 oflag=sync
1+0 records in
1+0 records out
327680 bytes (328 kB) copied, 46.2139 seconds, 7.1 kB/s

So it seems the speed is even slower when use a different IO scheduler.  By the way, the default IO scheduler in the stock DVSDK2 kernel (mv5, 2.6.18) is "Anticipatory", not CFQ, while the CFQ has no slice_idle parameter in the kernel config.  It makes me wonder if you are using a different kernel or so.

Hi David,

I assumed 2.6.37 kernel. I don't have a 2.6.18 setup with me now. Could you please try these options?

1. Could you please try with block sizes 1 byte, 1KB, 128KB, 1MB and with a bigger count and let me know the output? 

2. Try with oflag=sync,direct ?

3. What is the throughput without the oflag=sync?

4. Try using ext2 filesystem. This will disable journaling in ext3.

5. See kernel config whether CONFIG_NO_HZ is enabled or not? If its enabled disable it using menuconfig make it tick based system. 

6. If its already tick based system, see the value of CONFIG_HZ. See whether its >= 100?

-Renjith

www.pathpartnertech.com

Hi Renjith,

Thanks for the suggestions.  I will try them out later.  Somehow I suspect it's about EDMA driver as I can see a big difference there when I was trying to backport PSP 3.01 driver to DVSDK 2 (unsuccessfully).

Also it is not a problem of "dd" command and doesn't matter what parameters/options I use.  The real problem is the SD drive can not write back to the physical media with normal speed.  So it will happen when umount SD file system or reboot or anything else requires the writeback.  I'm using ext2 file system with noatime, so I can confirm it's a file system issue.

In kernel config, CONFIG_NO_HZ is not set and CONFIG_HZ is set to 100.

Thanks,
David 

David,

I don't suspect the SD driver. Could you please let me know the throughput with the sync flag? Also could you please share the results of running the dd command with different block sizes? That will be helpful for me to analyze. Most probably the issue will be with the Linux Block layer.

Regards,
Renjith 

Hi Renjith, please check the results below.  I had to interrupt the test "bs=128K count=128" and "bs=1M count=128" as they seemed running for ever.  The "oflag=sync,direct" is not a supported option in the "dd" provided by the original TI root file system.

/ # /tmp/dd if=/dev/zero of=zero bs=1 count=128 oflag=sync 

128+0 records in
128+0 records out
128 bytes (128 B) copied, 59.6349 seconds, 0.0 kB/s
/ # /tmp/dd if=/dev/zero of=zero bs=1K count=128 oflag=sync
29+0 records in
29+0 records out
29696 bytes (30 kB) copied, 12.8757 seconds, 2.3 kB/s

/ # /tmp/dd if=/dev/zero of=zero bs=1K count=128 oflag=sync
128+0 records in
128+0 records out
131072 bytes (131 kB) copied, 68.0895 seconds, 1.9 kB/s
/ # /tmp/dd if=/dev/zero of=zero bs=128K count=128 oflag=sync
38+0 records in
38+0 records out
4980736 bytes (5.0 MB) copied, 471.214 seconds, 10.6 kB/s

/ # /tmp/dd if=/dev/zero of=zero bs=1M count=128 oflag=sync
6+0 records in
6+0 records out
6291456 bytes (6.3 MB) copied, 555.62 seconds, 11.3 kB/s

/ # /tmp/dd if=/dev/zero of=zero bs=1 count=128 oflag=sync,direct
/tmp/dd: writing `zero': Invalid argument
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.00515819 seconds, 0.0 kB/s
/ # /tmp/dd if=/dev/zero of=zero bs=1 count=128
128+0 records in
128+0 records out
128 bytes (128 B) copied, 0.00365578 seconds, 35.0 kB/s
/ # /tmp/dd if=/dev/zero of=zero bs=1K count=128
128+0 records in
128+0 records out
131072 bytes (131 kB) copied, 0.00818115 seconds, 16.0 MB/s
/ # /tmp/dd if=/dev/zero of=zero bs=128K count=128
128+0 records in
128+0 records out
16777216 bytes (17 MB) copied, 0.436453 seconds, 38.4 MB/s

David,

Thanks for trying out these commands. Finally I found the real issue with MMC. There was no support for multi-block write in the driver. Whereas multi-block read was supported. Now I'm getting 650+ KB/sec throughput in sync mode.

I'm unable to attach the patch because of a silverlight plug-in issue. Could you please send a mail from your e-mail, so that I can send you the patch.

# /root/dd if=/dev/zero of=/root/temp/dum4 bs=128K count=200 oflag=sync
54+0 records in
54+0 records out
7077888 bytes (7.1 MB) copied, 10.7622 s, 658 kB/s

# /root/dd if=/dev/zero of=/root/temp/dum4 bs=128K count=100 oflag=sync
100+0 records in
100+0 records out
13107200 bytes (13 MB) copied, 19.4882 s, 673 kB/s

Enjoi,

Renjith, I really appreciate your efforts.  I just tried the patch and it passed the initial tests.  Just post Renjith's patch below as pure text in case someone else needs it:

From d590fb868875306f31b931ec03ccdbac278808a8 Mon Sep 17 00:00:00 2001
From: Renjith Thomas <renjith.thomas@pathpartnertech.com>
Date: Thu, 14 Jun 2012 20:18:20 +0530
Subject: [PATCH] Add multi-block write support for mmc/sd

Signed-off-by: Renjith Thomas <renjith.thomas@pathpartnertech.com>
---
 drivers/mmc/mmc_block.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc_block.c b/drivers/mmc/mmc_block.c
index 67289a8..5efa1d3 100644
--- a/drivers/mmc/mmc_block.c
+++ b/drivers/mmc/mmc_block.c
@@ -184,9 +184,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
             brq.cmd.opcode = brq.data.blocks > 1 ? MMC_READ_MULTIPLE_BLOCK : MMC_READ_SINGLE_BLOCK;
             brq.data.flags |= MMC_DATA_READ;
         } else {
-            brq.cmd.opcode = MMC_WRITE_BLOCK;
+            brq.cmd.opcode = brq.data.blocks > 1 ? MMC_WRITE_MULTIPLE_BLOCK : MMC_WRITE_BLOCK;
             brq.data.flags |= MMC_DATA_WRITE;
-            brq.data.blocks = 1;
         }
 
         if (brq.data.blocks > 1) {
--
1.7.5.4