From: Arnd Bergmann <arnd@arndb.de>
To: Andrei Warkentin <andreiw@motorola.com>
Cc: linux-mmc@vger.kernel.org
Subject: Re: [RFC 4/5] MMC: Adjust unaligned write accesses.
Date: Thu, 10 Mar 2011 17:05:45 +0100 [thread overview]
Message-ID: <201103101705.45230.arnd@arndb.de> (raw)
In-Reply-To: <1299718449-15172-5-git-send-email-andreiw@motorola.com>
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 <andreiw@motorola.com>
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
next prev parent reply other threads:[~2011-03-10 16:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 0:54 Block quirks redux + Toshiba performance quirk Andrei Warkentin
2011-03-10 0:12 ` Andrei Warkentin
2011-03-10 0:54 ` [RFC 1/5] MMC: Extends card quicks with MMC/SD quirks matching the CID Andrei Warkentin
2011-03-10 0:54 ` [RFC 2/5] MMC: Allow function-specific quirks Andrei Warkentin
2011-03-10 15:09 ` Arnd Bergmann
2011-03-10 20:41 ` Andrei Warkentin
2011-03-10 21:55 ` Arnd Bergmann
2011-03-10 0:54 ` [RFC 3/5] MMC: Support for block quirks Andrei Warkentin
2011-03-10 0:54 ` [RFC 4/5] MMC: Adjust unaligned write accesses Andrei Warkentin
2011-03-10 16:05 ` Arnd Bergmann [this message]
2011-03-10 20:45 ` Andrei Warkentin
2011-03-10 21:54 ` Arnd Bergmann
2011-03-10 23:06 ` Andrei Warkentin
2011-03-11 10:23 ` Arnd Bergmann
2011-03-13 13:00 ` Andrei Warkentin
2011-03-13 14:54 ` Arnd Bergmann
2011-03-14 7:40 ` Andrei Warkentin
2011-03-19 11:09 ` Andrei Warkentin
2011-03-21 14:21 ` Arnd Bergmann
2011-03-21 14:41 ` Andrei Warkentin
2011-03-21 18:03 ` Andreas Dilger
2011-03-21 19:05 ` Arnd Bergmann
2011-03-21 23:58 ` Andreas Dilger
2011-03-22 13:56 ` Arnd Bergmann
2011-03-22 15:02 ` Andreas Dilger
2011-03-22 15:44 ` Arnd Bergmann
2011-03-10 0:54 ` [RFC 5/5] MMC: Toshiba eMMC - Split 8K-unaligned accesses Andrei Warkentin
2011-03-10 1:03 ` [RFC] MMC: Extends card quicks with MMC/SD quirks matching the CID Andrei Warkentin
-- strict thread matches above, loose matches on Subject: below --
2011-03-21 14:27 Fwd: Re: [RFC 4/5] MMC: Adjust unaligned write accesses Arnd Bergmann
2011-03-21 23:45 ` Andreas Dilger
2011-03-22 7:18 ` Andrei Warkentin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103101705.45230.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=andreiw@motorola.com \
--cc=linux-mmc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.