MMC quirks relating to performance/lifetime.
Andrei Warkentin
andreiw at motorola.com
Tue Feb 22 02:05:38 EST 2011
On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> The description of the test case is probably suboptimal. What this does
> is 32 KB accesses, with 32 KB alignment in the pre and post case, but 16 KB
> alignment in the "on" case. The idea here is that it should never do
> any access with less than "--blocksize" aligment.
>
Now I feel slightly confused :(.
-b 16384 implies blocksize = 16384, maxalign is 8mb due to count 32,
ret = time_rw_interval(dev, count, pre, blocksize,
align - blocksize, maxalign,
do_write); //
<----------------- read 16k at align - 16k with 8mb intervals?
returnif(ret);
ret = time_rw_interval(dev, count, on, blocksize,
align - blocksize / 2, maxalign,
do_write); //
<----------------- read 16k at align - 8k with 8mb intervals?
returnif(ret);
ret = time_rw_interval(dev, count, post, blocksize,
align, maxalign, do_write); //
<-------- read 16k at align with 8mb intervals?
returnif(ret);
I hope I'm not missing something obvious...
> This is what I think happens:
> Since the partition is over 64 MB size and it can have 7 4 MB allocation units open,
> writing to 8 locations on the drive separated 8 MB causes it to do garbage collection
> all the time for 32KB accesses and larger. However, the "on" measurement is only
> 16 KB aligned, so it goes into T's buffer A for small writes, and does not hit
> the garbage collection all the time, so it ends up being a lot faster.
>
Can't go to A. A is 8KB big. Strange...
A
More information about the linux-arm-kernel
mailing list