Thread (62 messages) 62 messages, 9 authors, 2011-03-08

MMC quirks relating to performance/lifetime.

From: arnd@arndb.de (Arnd Bergmann)
Date: 2011-02-19 11:20:54
Also in: linux-mmc

On Saturday 19 February 2011 00:17:51 Andrei Warkentin wrote:
# echo 0 > /sys/block/mmcblk0/device/page_size
# ./flashbench -A -b 1024 /dev/block/mmcblk0p9
write align 8388608     pre 3.59ms      on 6.54ms       post 3.65ms     diff 2.92ms
write align 4194304     pre 4.13ms      on 7.37ms       post 4.27ms     diff 3.17ms
write align 2097152     pre 3.62ms      on 6.81ms       post 3.94ms     diff 3.03ms
write align 1048576     pre 3.62ms      on 6.53ms       post 3.55ms     diff 2.95ms
write align 524288      pre 3.62ms      on 6.51ms       post 3.63ms     diff 2.88ms
write align 262144      pre 3.62ms      on 6.51ms       post 3.63ms     diff 2.89ms
write align 131072      pre 3.62ms      on 6.5ms        post 3.63ms     diff 2.88ms
write align 65536       pre 3.61ms      on 6.49ms       post 3.62ms     diff 2.88ms
write align 32768       pre 3.61ms      on 6.49ms       post 3.61ms     diff 2.88ms
write align 16384       pre 3.68ms      on 107ms        post 3.51ms     diff 103ms
write align 8192        pre 3.74ms      on 121ms        post 3.91ms     diff 117ms
write align 4096        pre 3.88ms      on 3.87ms       post 3.87ms     diff -2937ns
write align 2048        pre 3.89ms      on 3.88ms       post 3.88ms     diff -8734ns
# fjnh84 at fjnh84-desktop:~/src/n/src/flash$ adb -s 17006185428011d7 shell
# echo 8192 > /sys/block/mmcblk0/device/page_size
# cd data
# ./flashbench -A -b 1024 /dev/block/mmcblk0p9
write align 8388608     pre 3.33ms      on 6.8ms        post 3.65ms     diff 3.31ms
write align 4194304     pre 4.34ms      on 8.14ms       post 4.53ms     diff 3.71ms
write align 2097152     pre 3.64ms      on 7.31ms       post 4.09ms     diff 3.44ms
write align 1048576     pre 3.65ms      on 7.52ms       post 3.65ms     diff 3.87ms
write align 524288      pre 3.62ms      on 6.8ms        post 3.63ms     diff 3.17ms
write align 262144      pre 3.62ms      on 6.84ms       post 3.63ms     diff 3.22ms
write align 131072      pre 3.62ms      on 6.85ms       post 3.44ms     diff 3.32ms
write align 65536       pre 3.39ms      on 6.8ms        post 3.66ms     diff 3.28ms
write align 32768       pre 3.64ms      on 6.86ms       post 3.66ms     diff 3.21ms
write align 16384       pre 3.67ms      on 6.86ms       post 3.65ms     diff 3.2ms
write align 8192        pre 3.66ms      on 6.84ms       post 3.64ms     diff 3.19ms
write align 4096        pre 3.71ms      on 3.71ms       post 3.64ms     diff 38.6?s
write align 2048        pre 3.71ms      on 3.71ms       post 3.72ms     diff -656ns

This was with the split unaligned accesses patch... Which I am
attaching for comments.
I agree, this is very fascinating behavior. 100ms second latency for a
single 2KB access is definitely something we should try to avoid, and I
wonder why the drive decides to do that. It must get into a state where
it requires an extra garbage collection (you mentioned that earlier).

The numbers you see here are taken over multiple runs. Do you see a lot
of fluctuation when doing this with --count=1?

Also, does the same happen with other blocksizes, e.g. 4096 or 8192, passed
to flashbench?

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help