On Thursday 10 March 2011, Andrei Warkentin wrote:
> Adjust unaligned write accesses spanning preferred align
> size into two accesses - an unaligned and an aligned access.
> This is meant to be used for card quirks, and is off
> by default. A limiting value in transfer size
> for this adjustment is available, as on some cards there is a
> perf decrease for larger transfers.
> 
> Signed-off-by: Andrei Warkentin <[email protected]>

Sorry for repeating myself, but I'm not sure if you didn't understand
me or if I missed your arguments against the more generic approach.

Instead of encoding specific parameters for this quirk, I would
much prefer to have the values be meaningful, and have the
code deal with the interpretation.

> @@ -63,6 +63,8 @@ struct mmc_blk_data {
>  
>       unsigned int    usage;
>       unsigned int    read_only;
> +     unsigned int    write_align_size;
> +     unsigned int    write_align_limit;
>  };

These numbers are generally speaking useless, except for the
one quirk. What I was trying to suggest here is to have
a page_size field that reflects the underlying page size
of the NAND flash, and a flag that says "please split all
requests under 1.5 times the page size along page boundaries".

We can pre-initialize the page size to some common value
(e.g. 16 KB for 4GB or larger cards, 4 KB for smaller than
4 GB), and use quirks to override it for cards where we
know it's different.

There are a lot of optimizations based on the page size
(partition alignment, fs block size, readahead, ...), so it
can become a generic blockdev attribute and get used by
both kernel and user code, rather than assuming we can
do 512 byte sector accesses efficiently.

The block layer already has physical_block_size and
io_min fields in various places, so the answer may be
to simply set one of those instead of introducing another
page_size for mmc.

        Arnd
--
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

Reply via email to