From: Andrew Morton <akpm@zip.com.au>
To: vda@port.imtp.ilyichevsk.odessa.ua
Cc: Ken <koehlekr@ucrwcu.rwc.uc.edu>,
linux-kernel@vger.kernel.org, bugs@linux-ide.org
Subject: Re: 2.4.17 multiple Oops and file corruption on I845 MB
Date: Thu, 24 Jan 2002 12:52:15 -0800 [thread overview]
Message-ID: <3C5073FF.E9A2806@zip.com.au> (raw)
In-Reply-To: <3C4EE4C8.6FF3B2AF@ucrwcu.rwc.uc.edu>, <3C4EE4C8.6FF3B2AF@ucrwcu.rwc.uc.edu> <200201241454.g0OEsIE11368@Port.imtp.ilyichevsk.odessa.ua>
Denis Vlasenko wrote:
>
> Hmm... what about de-inlining __wake_up_common? It is called in several places,
>
The kernel inlines stuff too much, and we're sloshing
vast amounts of stuff across the memory bus needlessly.
I suspect this is a more important issue than all the
stupid FASTCALL, likely() and `goto out_of_line' crud.
I chose to inline __wake_up_common() when I did the
try_to_wake_up() stuff because __wake_up_sync() is almost
never used, and the only other call site was __wake_up().
But now complete() is there too, Its main use will be in
disk driver calls - things like IDE CDROM where `ide_wait'
is used. Also SCSI uses complete() for synchronous operations
such as ioctls, disk spin-up, etc. I don't think scsi
uses complete() on a common path.
So __wake_up() remains the single main user of
__wake_up_common(), so __wake_up_common() should remain inline.
-
next prev parent reply other threads:[~2002-01-24 21:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-23 16:28 2.4.17 multiple Oops and file corruption on I845 MB Ken
2002-01-24 18:54 ` Denis Vlasenko
2002-01-24 20:52 ` Andrew Morton [this message]
2002-01-27 19:47 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2002-01-24 22:09 ken
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=3C5073FF.E9A2806@zip.com.au \
--to=akpm@zip.com.au \
--cc=bugs@linux-ide.org \
--cc=koehlekr@ucrwcu.rwc.uc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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.