linux-kernel - Re: [PATCH] mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1107131031360.3174@lazy>
Date:	Wed, 13 Jul 2011 10:42:32 -0500 (CDT)
From:	Manoj Iyer <manoj.iyer@...onical.com>
To:	Chris Ball <cjb@...top.org>
cc:	Arnd Bergmann <arnd@...db.de>,
	Manoj Iyer <manoj.iyer@...onical.com>,
	linux-kernel@...r.kernel.org, jbarnes@...tuousgeek.org,
	matsumur@....ricoh.co.jp, linux-pci@...r.kernel.org,
	linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc: Added quirks for Ricoh 1180:e823 lower base clock
 frequency


Chris/Arnd,

Here is a series of test I did with the patched kernel.


== cold boot insert SD card ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    4.96M/s
2MiB    6.3M/s
1MiB    6.23M/s
512KiB  6.23M/s
256KiB  6.26M/s

== rerun the same test 2nd time ===
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    6.28M/s
2MiB    6.29M/s
1MiB    6.29M/s
512KiB  6.29M/s
256KiB  6.26M/s

== remove and reinsert the SD card ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    6.42M/s
2MiB    6.28M/s
1MiB    6.22M/s
512KiB  6.23M/s
256KiB  6.26M/s

== remove and reinsert the SD card ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    6.42M/s
2MiB    6.3M/s
1MiB    6.22M/s
512KiB  6.25M/s
256KiB  6.24M/s

== reboot, reinsert the SD card ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
[sudo] password for u:
4MiB    6.45M/s
2MiB    6.33M/s
1MiB    6.25M/s
512KiB  6.29M/s
256KiB  6.3M/s
u@u:~/flash/flashbench$

== rerun the test again ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    6.27M/s
2MiB    6.27M/s
1MiB    6.28M/s
512KiB  6.27M/s
256KiB  6.24M/s
u@u:~/flash/flashbench$

== poweroff, Poweron, insert SD card ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
[sudo] password for u:
4MiB    6.45M/s
2MiB    6.33M/s
1MiB    6.24M/s
512KiB  6.29M/s
256KiB  6.32M/s
u@u:~/flash/flashbench$

== rerun the test again ==
u@u:~/flash/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 1024 * 
1024] --blocksize=$[256 * 1024] /dev/mmcblk0  --open-au-nr=2
4MiB    6.29M/s
2MiB    6.28M/s
1MiB    6.29M/s
512KiB  6.28M/s
256KiB  6.25M/s
u@u:~/flash/flashbench$

On Wed, 13 Jul 2011, Chris Ball wrote:

> Hi Arnd,
>
> On Tue, Jul 12 2011, Arnd Bergmann wrote:
>> I would very much expect that to be nonreproducible. The first row
>> in each test is the result of a single write() system call and does
>> not get averaged out. More importantly the time for each write
>> depends a lot of the state of the card before the write.
>>
>> For instance when you do a lot of random writes to a card, optionally
>> take it out and put it into a different machine, and then do a large
>> linear write, that linear write will be very slow because the
>> card has to garbage collect all the random writes that were done
>> earlier. After a few writes (usually one is enough), it gets back
>> to the full performance.
>
> That makes sense.  Do you think this explains Manoj getting a slower
> first file copy speed (757ms vs. 480ms) after applying his patch?
> (Manoj, perhaps you could retry your test without GC being needed?)
>
> What would we expect lowering the SD base clock frequency from 200MHz
> to 50MHz to do to performance theoretically?
>
> Thanks,
>
> - Chris.
> -- 
> Chris Ball   <cjb@...top.org>   <http://printf.net/>
> One Laptop Per Child
>
>

--
====================
Manoj Iyer
Ubuntu/Canonical
Hardware Enablement
====================
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/