On Saturday 09 July 2011 00:04:24 Peter Warasin wrote:
is the garbage collector slow and running all the time after 2nd try?
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O 4MiB 2.16M/s 2MiB 2.86M/s 1MiB 4.2M/s 512KiB 1.47M/s 256KiB 735K/s 128KiB 904K/s 64KiB 1.12M/s 32KiB 550K/s 16KiB 360K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O 4MiB 3.5M/s 2MiB 6.58M/s 1MiB 9.5M/s 512KiB 1.49M/s 256KiB 734K/s 128KiB 986K/s 64KiB 1.17M/s 32KiB 589K/s 16KiB 369K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O 4MiB 647K/s 2MiB 603K/s 1MiB 604K/s 512KiB 631K/s 256KiB 745K/s 128KiB 987K/s 64KiB 1.17M/s 32KiB 588K/s 16KiB 309K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O 4MiB 652K/s 2MiB 599K/s 1MiB 604K/s 512KiB 636K/s 256KiB 736K/s 128KiB 1M/s 64KiB 1.16M/s 32KiB 540K/s 16KiB 352K/s
The lower lines are fairly consistent, the upper ones are not. This is a strong indication that the erase block size is not really 4MB but something else, probably a multiple of 3 even. In the lower lines, it all averages out, while at the top there are only a few system calls and doing one GC impacts the timing significantly.
Best try a few other erasesize values:
./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[1024 * 1024] --blocksize=$[64 * 1024] ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[1536 * 1024] --blocksize=$[96 * 1024] ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[2048 * 1024] --blocksize=$[64 * 1024] ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[3072 * 1024] --blocksize=$[96 * 1024] ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[6144 * 1024] --blocksize=$[96 * 1024] ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[8192 * 1024] --blocksize=$[64 * 1024]
Try each one a few times. If you get to the correct erasesize value, the results should be both faster and more stable.
what i also noticed on this card is that the card is running with legacy timing instead of high-speed:
cat /sys/kernel/debug/mmc0/ios clock: 25000000 Hz vdd: 20 (3.2 ~ 3.3 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 0 (legacy)
i tried to figure out why, but most probably i guess the card will respond with SCR_SPEC_VER_1 for sda_vsn i *think*, since the controller (marvell/mvsdio) is MMC_CAP_SD_HIGHSPEED capable and i see no kernel warnings that the card is not able to do mandatory switch function will try to hardcode to SD_HIGHSPEED next week.. (for testing) could that help or is it completely irrelevant?
I don't really know. Best ask this question on the linux-mmc mailing list.
during bonnie tests we had a high cpu load (90%),.. and during normal operation of the system iowait is going up really high (90%) which freezes the system then
is that normal? shouldn't most calculation being done by the microcontroller on the SD chip?
I haven't tried it, but bonnie is really totally useless on SD cards, and it's absolutely possible that this is always the case.
it's always the case, that the cpu load is that high only with bonnie, or under normal circumstances?
I mean with bonnie.
i ask because someone on #linaro asked me if the device is probably not dma enabled or in 1-bit mode, which would make sense i think that if it is not dma enabled it uses cpu for everything..
however, i figured out that it is not in 1-bit mode, it is in 4-bit mode, good i guess .. but i was not able how to figure out if it is dma enabled or not. i found nothing in sourcecode but how to disable dma during loading the module, which does not apply, since the driver is compiled in.
You can pass module options through the boot loader, in the kernel command line, like 'modulename.option=value'.
Also, there is no need to run the SD card test on the target hardware. Best do the same test on a PC with a USB card reader or builtin SD card slot and see if the numbers are much different. If everything's faster but the behaviour otherwise the same, there is probably also a bug in the host driver.
Arnd