From: Mark Lord <liml@rtr.ca>
To: Andreas Mohr <andi@lisas.de>
Cc: linux-ide@vger.kernel.org
Subject: Re: linux/libata.h/ata_busy_wait() inefficiencies?
Date: Wed, 26 Mar 2008 10:11:37 -0400 [thread overview]
Message-ID: <47EA5999.2010500@rtr.ca> (raw)
In-Reply-To: <20080325205904.GA19388@rhlx01.hs-esslingen.de>
Andreas Mohr wrote:
> Hello all,
>
> originally I just intended to prepare a patch (to -mm),
> but it seems better to discuss this first.
>
> Currently (2.6.25-rc6) we have:
>
> static inline u8 ata_busy_wait(struct ata_port *ap, unsigned int bits,
> unsigned int max)
> {
> u8 status;
>
> do {
> udelay(10);
> status = ata_chk_status(ap);
> max--;
> } while (status != 0xff && (status & bits) && (max > 0));
>
> return status;
> }
>
> This can easily be improved to have merged max handling
> by doing a single (--max > 0) instead, without any change in behaviour.
> Building this on i386 showed combined image savings of almost 100 bytes,
> most likely due to not having to re-fetch max again for the duplicate
> max access.
>
> However we're not finished yet:
> Since status != 0xff is most certainly a check for the "unplugged hotplug"
> case, it's a bit wasteful to check this as the very first abort condition.
> By moving this more towards the end one should be able to improve exit latency
> of this loop, without altering behaviour here as well (- right??).
> Since the "(status != 0xff && (status & bits)" part is being used verbatim
> (ICK, COPY&PASTE!! ;) many times (e.g. also in libata-core.c),
> IMHO the best way going forward would be to create another fittingly named
> inline header helper for this combined check which could then have its
> check order swapped for better exit latency.
>
> Those two tweaks alone may already be able to deliver a noticeable speedup
> of ata operations given that this is frequently used inner libata code.
..
While you're at it, the udelay(10) should really be *much* smaller,
or at least broken into a top/bottom pair of udelay(5). I really suspect
that much of the time, the status value is satisified on the first iteration,
requiring no more than a microsecond or so. Yet we always force it to take
at least 10us, or about 15000 instructions worth on a modern CPU.
Cheers
next prev parent reply other threads:[~2008-03-26 14:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 20:59 linux/libata.h/ata_busy_wait() inefficiencies? Andreas Mohr
2008-03-26 14:11 ` Mark Lord [this message]
2008-03-26 21:34 ` Alan Cox
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=47EA5999.2010500@rtr.ca \
--to=liml@rtr.ca \
--cc=andi@lisas.de \
--cc=linux-ide@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.