From: Arnd Bergmann <arnd@arndb.de>
To: Andrei Warkentin <andreiw@motorola.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
linux-mmc@vger.kernel.org
Subject: Re: MMC quirks relating to performance/lifetime.
Date: Fri, 25 Feb 2011 13:21:09 +0100 [thread overview]
Message-ID: <201102251321.09232.arnd@arndb.de> (raw)
In-Reply-To: <AANLkTikWKk0kE=Hh4gfA6Mwt+-65TVFnBcOYy_eRuQfw@mail.gmail.com>
On Friday 25 February 2011, Andrei Warkentin wrote:
> Yup. I understand :-). That's the strategy I'm going to follow. For
> page_size-alignment/splitting I'm looking at the block layer now. Is
> that the right approach or should I still submit a (cleaned up) patch
> to mmc/card/block.c for that performance improvement.
I guess it should live in block/cfq-iosched in the long run, but I don't
know how easy it is to implement it there for test purposes.
It may be easier to prototype it in the mmc code, since you are more
familiar with that already, post that patch together with benchmark
results and then do a new patch for the final solution. We'll need
more benchmarking to figure out if that should be applied for
all nonrotational storage, or if there are cases where it actually
hurts performance to split requests on page boundaries.
If it turns out to be a good idea in general, we won't even need a
sysfs interface for enabling it, just one for reading/writing the
underlying page size.
> The other (Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c.
Makes sense.
Arnd
next prev parent reply other threads:[~2011-02-25 12:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTikh4vfS7SLKAa-aUXhbTxcHzYHmBuaXj1qHHYN9@mail.gmail.com>
[not found] ` <201102171647.46190.arnd@arndb.de>
[not found] ` <AANLkTimGrT_p_5xdXJv5UURPMC0cwJCPkZ=xcX5Nk=o=@mail.gmail.com>
2011-02-20 14:39 ` MMC quirks relating to performance/lifetime Arnd Bergmann
2011-02-22 7:46 ` Andrei Warkentin
2011-02-22 17:00 ` Arnd Bergmann
2011-02-23 10:19 ` Andrei Warkentin
2011-02-23 16:09 ` Arnd Bergmann
2011-02-23 22:26 ` Andrei Warkentin
2011-02-24 9:24 ` Arnd Bergmann
2011-02-25 11:02 ` Andrei Warkentin
2011-02-25 12:21 ` Arnd Bergmann [this message]
2011-03-01 18:48 ` Jens Axboe
2011-03-01 19:11 ` Arnd Bergmann
2011-03-01 19:15 ` Jens Axboe
2011-03-01 19:51 ` Arnd Bergmann
2011-03-01 21:33 ` Andrei Warkentin
2011-03-02 10:34 ` Andrei Warkentin
2011-03-05 9:23 ` Andrei Warkentin
[not found] ` <201102111551.15508.arnd@arndb.de>
[not found] ` <20110308065911.GC1357@ucw.cz>
2011-03-08 14:03 ` Arnd Bergmann
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=201102251321.09232.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=andreiw@motorola.com \
--cc=axboe@kernel.dk \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).