On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
