Flashbench results for Micron MTFC2GMVEA-0M WT 2GB eMMC.
root@beaglebone:~/flashbench# head /sys/block/mmcblk1/device/* 2>/dev/null | grep -v ^$ ==> /sys/block/mmcblk1/device/block <== ==> /sys/block/mmcblk1/device/cid <== fe014e4d4d433032473a1158f1467f35 ==> /sys/block/mmcblk1/device/csd <== d04f01320f5a1393ffffffe38a4000e7 ==> /sys/block/mmcblk1/device/date <== 07/2012 ==> /sys/block/mmcblk1/device/driver <== ==> /sys/block/mmcblk1/device/enhanced_area_offset <== 18446744073709551594 ==> /sys/block/mmcblk1/device/enhanced_area_size <== 4294967274 ==> /sys/block/mmcblk1/device/erase_size <== 524288 ==> /sys/block/mmcblk1/device/fwrev <== 0x0 ==> /sys/block/mmcblk1/device/hwrev <== 0x0 ==> /sys/block/mmcblk1/device/manfid <== 0x0000fe ==> /sys/block/mmcblk1/device/name <== MMC02G ==> /sys/block/mmcblk1/device/oemid <== 0x014e ==> /sys/block/mmcblk1/device/power <== ==> /sys/block/mmcblk1/device/preferred_erase_size <== 4194304 ==> /sys/block/mmcblk1/device/raw_rpmb_size_mult <== 0x1 ==> /sys/block/mmcblk1/device/rel_sectors <== 0x1 ==> /sys/block/mmcblk1/device/serial <== 0x1158f146 ==> /sys/block/mmcblk1/device/subsystem <== ==> /sys/block/mmcblk1/device/type <== MMC ==> /sys/block/mmcblk1/device/uevent <== DRIVER=mmcblk MMC_TYPE=MMC MMC_NAME=MMC02G MODALIAS=mmc:block
root@beaglebone:~/flashbench# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000600 HCTL: 0x00000b06 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
root@beaglebone:~/flashbench# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 46.5893 s, 5.8 MB/s
root@beaglebone:~/flashbench# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 15.1334 s, 17.7 MB/s
root@beaglebone:~/flashbench# fdisk -l /dev/mmcblk1 Disk /dev/mmcblk1: 1920 MB, 1920991232 bytes 4 heads, 16 sectors/track, 58624 cylinders, total 3751936 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
root@beaglebone:~/flashbench# ./flashbench -a /dev/mmcblk1 --blocksize=1024 --count=100 align 536870912 pre 1.03ms on 1.48ms post 1.03ms diff 451µs align 268435456 pre 1ms on 1.41ms post 1.01ms diff 403µs align 134217728 pre 978µs on 1.44ms post 918µs diff 488µs align 67108864 pre 932µs on 1.26ms post 782µs diff 407µs align 33554432 pre 981µs on 1.35ms post 923µs diff 393µs align 16777216 pre 988µs on 1.43ms post 992µs diff 442µs align 8388608 pre 993µs on 1.44ms post 989µs diff 446µs align 4194304 pre 904µs on 1.22ms post 740µs diff 398µs align 2097152 pre 992µs on 1.44ms post 984µs diff 448µs align 1048576 pre 989µs on 1.05ms post 991µs diff 57.4µs align 524288 pre 989µs on 1.05ms post 992µs diff 62.4µs align 262144 pre 743µs on 801µs post 746µs diff 56.4µs align 131072 pre 986µs on 1.05ms post 992µs diff 59µs align 65536 pre 983µs on 1.04ms post 987µs diff 54.7µs align 32768 pre 982µs on 1.04ms post 985µs diff 58.6µs align 16384 pre 953µs on 1ms post 937µs diff 55.3µs align 8192 pre 742µs on 794µs post 738µs diff 54µs align 4096 pre 979µs on 1.04ms post 985µs diff 57.5µs align 2048 pre 982µs on 1.02ms post 982µs diff 41.3µs
## Looks like 2 MiB erase blocks
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=1 2MiB 2.52M/s 1MiB 2.47M/s 512KiB 2.52M/s 256KiB 2.49M/s 128KiB 2.48M/s 64KiB 2.49M/s 32KiB 2.34M/s 16KiB 2.13M/s 8KiB 1.82M/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=5 2MiB 4.49M/s 1MiB 3.84M/s 512KiB 4.42M/s 256KiB 4.34M/s 128KiB 4.23M/s 64KiB 4.14M/s 32KiB 3.34M/s 16KiB 1.22M/s 8KiB 927K/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=6 2MiB 5.66M/s 1MiB 3.33M/s 512KiB 1.27M/s 256KiB 598K/s ^C
## 5 open-au non-random
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=5 --random 2MiB 6.16M/s 1MiB 1.6M/s 512KiB 2.48M/s 256KiB 2.51M/s 128KiB 1.64M/s 64KiB 1.27M/s 32KiB 1.07M/s 16KiB 1.21M/s 8KiB 886K/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=6 --random 2MiB 5.37M/s 1MiB 3.35M/s 512KiB 1.28M/s 256KiB 601K/s 128KiB 295K/s ^C
## 5 open-au in random, too
I expected better but this is a lower end eMMC from Micron.
-Andrew
Yes, it is a lower end version. Something about a lower cost.
Gerald
On Thu, Jan 31, 2013 at 1:42 PM, Andrew Bradford < andrew@bradfordembedded.com> wrote:
Flashbench results for Micron MTFC2GMVEA-0M WT 2GB eMMC.
root@beaglebone:~/flashbench# head /sys/block/mmcblk1/device/* 2>/dev/null | grep -v ^$ ==> /sys/block/mmcblk1/device/block <== ==> /sys/block/mmcblk1/device/cid <== fe014e4d4d433032473a1158f1467f35 ==> /sys/block/mmcblk1/device/csd <== d04f01320f5a1393ffffffe38a4000e7 ==> /sys/block/mmcblk1/device/date <== 07/2012 ==> /sys/block/mmcblk1/device/driver <== ==> /sys/block/mmcblk1/device/enhanced_area_offset <== 18446744073709551594 ==> /sys/block/mmcblk1/device/enhanced_area_size <== 4294967274 ==> /sys/block/mmcblk1/device/erase_size <== 524288 ==> /sys/block/mmcblk1/device/fwrev <== 0x0 ==> /sys/block/mmcblk1/device/hwrev <== 0x0 ==> /sys/block/mmcblk1/device/manfid <== 0x0000fe ==> /sys/block/mmcblk1/device/name <== MMC02G ==> /sys/block/mmcblk1/device/oemid <== 0x014e ==> /sys/block/mmcblk1/device/power <== ==> /sys/block/mmcblk1/device/preferred_erase_size <== 4194304 ==> /sys/block/mmcblk1/device/raw_rpmb_size_mult <== 0x1 ==> /sys/block/mmcblk1/device/rel_sectors <== 0x1 ==> /sys/block/mmcblk1/device/serial <== 0x1158f146 ==> /sys/block/mmcblk1/device/subsystem <== ==> /sys/block/mmcblk1/device/type <== MMC ==> /sys/block/mmcblk1/device/uevent <== DRIVER=mmcblk MMC_TYPE=MMC MMC_NAME=MMC02G MODALIAS=mmc:block
root@beaglebone:~/flashbench# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000600 HCTL: 0x00000b06 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
root@beaglebone:~/flashbench# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 46.5893 s, 5.8 MB/s
root@beaglebone:~/flashbench# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 15.1334 s, 17.7 MB/s
root@beaglebone:~/flashbench# fdisk -l /dev/mmcblk1 Disk /dev/mmcblk1: 1920 MB, 1920991232 bytes 4 heads, 16 sectors/track, 58624 cylinders, total 3751936 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
root@beaglebone:~/flashbench# ./flashbench -a /dev/mmcblk1 --blocksize=1024 --count=100 align 536870912 pre 1.03ms on 1.48ms post 1.03ms diff 451µs align 268435456 pre 1ms on 1.41ms post 1.01ms diff 403µs align 134217728 pre 978µs on 1.44ms post 918µs diff 488µs align 67108864 pre 932µs on 1.26ms post 782µs diff 407µs align 33554432 pre 981µs on 1.35ms post 923µs diff 393µs align 16777216 pre 988µs on 1.43ms post 992µs diff 442µs align 8388608 pre 993µs on 1.44ms post 989µs diff 446µs align 4194304 pre 904µs on 1.22ms post 740µs diff 398µs align 2097152 pre 992µs on 1.44ms post 984µs diff 448µs align 1048576 pre 989µs on 1.05ms post 991µs diff 57.4µs align 524288 pre 989µs on 1.05ms post 992µs diff 62.4µs align 262144 pre 743µs on 801µs post 746µs diff 56.4µs align 131072 pre 986µs on 1.05ms post 992µs diff 59µs align 65536 pre 983µs on 1.04ms post 987µs diff 54.7µs align 32768 pre 982µs on 1.04ms post 985µs diff 58.6µs align 16384 pre 953µs on 1ms post 937µs diff 55.3µs align 8192 pre 742µs on 794µs post 738µs diff 54µs align 4096 pre 979µs on 1.04ms post 985µs diff 57.5µs align 2048 pre 982µs on 1.02ms post 982µs diff 41.3µs
## Looks like 2 MiB erase blocks
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=1 2MiB 2.52M/s 1MiB 2.47M/s 512KiB 2.52M/s 256KiB 2.49M/s 128KiB 2.48M/s 64KiB 2.49M/s 32KiB 2.34M/s 16KiB 2.13M/s 8KiB 1.82M/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=5 2MiB 4.49M/s 1MiB 3.84M/s 512KiB 4.42M/s 256KiB 4.34M/s 128KiB 4.23M/s 64KiB 4.14M/s 32KiB 3.34M/s 16KiB 1.22M/s 8KiB 927K/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=6 2MiB 5.66M/s 1MiB 3.33M/s 512KiB 1.27M/s 256KiB 598K/s ^C
## 5 open-au non-random
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=5 --random 2MiB 6.16M/s 1MiB 1.6M/s 512KiB 2.48M/s 256KiB 2.51M/s 128KiB 1.64M/s 64KiB 1.27M/s 32KiB 1.07M/s 16KiB 1.21M/s 8KiB 886K/s
root@beaglebone:~/flashbench# ./flashbench /dev/mmcblk1 --open-au --erasesize=$[2*1024*1024] --blocksize=$[8*1024] --open-au-nr=6 --random 2MiB 5.37M/s 1MiB 3.35M/s 512KiB 1.28M/s 256KiB 601K/s 128KiB 295K/s ^C
## 5 open-au in random, too
I expected better but this is a lower end eMMC from Micron.
-Andrew
-- You received this message because you are subscribed to the Google Groups "Beagle Alpha" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagle-alpha+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
On Thu, 31 Jan 2013 14:42:28 -0500 Andrew Bradford andrew@bradfordembedded.com wrote:
<snip>
root@beaglebone:~/flashbench# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000600 HCTL: 0x00000b06 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
Now in 8 bit mode:
root@beaglebone:~# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000620 HCTL: 0x00000b04 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
root@beaglebone:~/flashbench# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 46.5893 s, 5.8 MB/s
root@beaglebone:~/flashbench# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 15.1334 s, 17.7 MB/s
root@beaglebone:~# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 47.8116 s, 5.6 MB/s
root@beaglebone:~# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 11.9116 s, 22.5 MB/s
## Not quite the speeds listed in the Micron data sheet. ## Is better than 4 bit mode, though.
<snip>
In 8 bit mode, open-au tests look the same as 4 bit mode, which should be expected as the controller is the bottleneck on writes anyway.
-Andrew
One thing I am not sure of is if there are things we can do in the driver to improve things based on the Micron controller. One idea is that as we know the controller and are not subject to heaven only knows what controller is in the SD card a person buys. They are all over the map.
There is a mode that allows better performance, but it has some risks. I don't recall what they are. So if we can make the driver not generic, but specific, then we may be able to squeeze more out. I think it is worth looking into.
Gerald
On Fri, Feb 1, 2013 at 7:10 AM, Andrew Bradford <andrew@bradfordembedded.com
wrote:
On Thu, 31 Jan 2013 14:42:28 -0500 Andrew Bradford andrew@bradfordembedded.com wrote:
<snip>
root@beaglebone:~/flashbench# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000600 HCTL: 0x00000b06 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
Now in 8 bit mode:
root@beaglebone:~# cat /sys/kernel/debug/mmc1/* 2>/dev/null | grep -v ^$ 52000000 clock: 52000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) mmc1: ctx_loss: 0:0 regs: CON: 0x00000620 HCTL: 0x00000b04 SYSCTL: 0x000c0087 IE: 0x00000000 ISE: 0x00000000 CAPA: 0x06e10080
root@beaglebone:~/flashbench# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 46.5893 s, 5.8 MB/s
root@beaglebone:~/flashbench# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 15.1334 s, 17.7 MB/s
root@beaglebone:~# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 47.8116 s, 5.6 MB/s
root@beaglebone:~# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=256 iflag=direct 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 11.9116 s, 22.5 MB/s
## Not quite the speeds listed in the Micron data sheet. ## Is better than 4 bit mode, though.
<snip>
In 8 bit mode, open-au tests look the same as 4 bit mode, which should be expected as the controller is the bottleneck on writes anyway.
-Andrew
-- You received this message because you are subscribed to the Google Groups "Beagle Alpha" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagle-alpha+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
On Friday 01 February 2013, Gerald Coley wrote:
One thing I am not sure of is if there are things we can do in the driver to improve things based on the Micron controller. One idea is that as we know the controller and are not subject to heaven only knows what controller is in the SD card a person buys. They are all over the map.
The most important thing to do is to educate users that they need to align their partitions to the 2MB erase block boundary. There are still old manuals that recommend aligning the data partition to logical "cylinder" numbers, which makes the partition completely unaligned to the hardware geometry.
2MB erase block size isn't all that bad. Bigger eMMC chips can have 8MB erase blocks or worse, which is much harder to optimize for.
Using f2fs in Linux-3.8 and later should be a significant improvement over what you can expect with ext4 and btrfs today (I really hope that nobody uses ext3 any more, that would suck a much more on flash devices like this one). An aligned f2fs with 2MB log size should be just fine, although there is some debate over whether you should be using 4 or 6 logs in that case. Using 4 logs is better tuned to the hardware in this case, but 6 logs has better garbage collection in the file system, so answering this question needs some more benchmarking, and it may be workload dependent.
There is a mode that allows better performance, but it has some risks. I don't recall what they are. So if we can make the driver not generic, but specific, then we may be able to squeeze more out. I think it is worth looking into.
There isn't much on the driver level that you can do for a specific flash chip, it's all in the file system. I could ask my contacts at Micron though to see if there is a way to increase the number of concurrent erase blocks on this thing. This would make the boot time a little worse but give you better performance and less wear.
Arnd
flashbench-results@lists.linaro.org
-
Andrew Bradford -
Arnd Bergmann -
Gerald Coley