From: Chris Ball <cjb@laptop.org>
To: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: Matt Fleming <matt@console-pimps.org>,
Albert Herranz <albert_herranz@yahoo.es>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ben Dooks <ben-linux@fluff.org>,
Andrew Morton <akpm@linux-foundation.org>,
Pierre Ossman <pierre@ossman.eu>
Subject: Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
Date: Wed, 8 Sep 2010 23:05:48 +0100 [thread overview]
Message-ID: <20100908220548.GA7967@void.printf.net> (raw)
In-Reply-To: <20100908215750.GA17232@oksana.dev.rtsoft.ru>
Hi Anton,
On Thu, Sep 09, 2010 at 01:57:50AM +0400, Anton Vorontsov wrote:
> Thanks!
>
> Would be also great if you could point out which patch causes
> most of the performance drop (if any)?
>
> Albert, if you could find time, can you also "bisect" the
> patchset? I wouldn't want to buy Nintendo WII just to debug the
> perf regression. ;-) FWIW, I tried to disable multiblock
> read/writes and test with SD cards, and still didn't notice
> any performance drops.
>
> Maybe it's SDIO IRQs that cause the performance drop for the
> WII case, as we delay them a little bit? Or it could be the
> patch that introduces threaded IRQ handler in whole causes
> it. If so, I guess we'd need to move some of the processing to
> the real IRQ context, keeping the handler lockless (if
> possible) or introducing a very fine grained locking.
I didn't know anything about a reported performance drop, and I don't
think Andrew did either -- Albert's test results don't seem to have
made it to this list, or anywhere else that I can see. Could you
link to/repost his comments?
(I'll be testing with libertas, so that will stress-test SDIO IRQs.)
Thanks,
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
next prev parent reply other threads:[~2010-09-08 22:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-14 13:07 [PATCH 0/8] sdhci: Move real work out of an atomic context Anton Vorontsov
2010-07-14 13:07 ` [PATCH 1/8] sdhci: Turn timeout timer into delayed work Anton Vorontsov
2010-07-14 13:07 ` [PATCH 2/8] sdhci: Use work structs instead of tasklets Anton Vorontsov
2010-07-14 13:08 ` [PATCH 3/8] sdhci: Clear interrupt status register just once Anton Vorontsov
2010-07-14 13:08 ` [PATCH 4/8] sdhci: Use threaded IRQ handler Anton Vorontsov
2010-07-14 13:08 ` [PATCH 5/8] sdhci: Turn host->lock into a mutex Anton Vorontsov
2010-07-14 13:08 ` [PATCH 6/8] sdhci: Get rid of card detect work Anton Vorontsov
2010-07-14 13:08 ` [PATCH 7/8] sdhci: Get rid of mdelay()s where it is safe and makes sense Anton Vorontsov
2010-07-14 13:08 ` [PATCH 8/8] sdhci: Use jiffies instead of a timeout counter Anton Vorontsov
2010-07-15 6:02 ` [PATCH 0/8] sdhci: Move real work out of an atomic context Matt Fleming
2010-07-21 21:13 ` Andrew Morton
2010-09-07 22:38 ` Andrew Morton
2010-09-08 21:37 ` Chris Ball
2010-09-08 21:57 ` Anton Vorontsov
2010-09-08 22:05 ` Chris Ball [this message]
2010-09-08 22:27 ` Anton Vorontsov
2010-09-09 2:28 ` Chris Ball
2010-09-09 7:15 ` Anton Vorontsov
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=20100908220548.GA7967@void.printf.net \
--to=cjb@laptop.org \
--cc=akpm@linux-foundation.org \
--cc=albert_herranz@yahoo.es \
--cc=ben-linux@fluff.org \
--cc=cbouatmailru@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=matt@console-pimps.org \
--cc=pierre@ossman.eu \
/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).