From: James Bottomley <James.Bottomley@SteelEye.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: tglx@linutronix.de, Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] SCSI: Replace semaphores with wait_even
Date: 24 Oct 2004 20:02:24 -0400 [thread overview]
Message-ID: <1098662552.10824.369.camel@mulgrave> (raw)
In-Reply-To: <20041024230601.GA14956@elte.hu>
On Sun, 2004-10-24 at 19:06, Ingo Molnar wrote:
> i think i fixed this in my PREEMPT_REALTIME tree (having seen spinning
> eh_threads) - maybe Thomas forgot to merge those fixes back?
>
> (in a PREEMPT_REALTIME kernel a spinning thread is just a thread eating
> up CPU power, it doesnt cause a hang.)
I've really got to say, I don't like what you're doing. This program
seems to replace
if (condition)
up(sem);
[...]
down(sem);
with
if (condition)
up(event_queue);
[...]
wait_event(event_queue, condition);
That can be wrong on three counts:
1) The condition is a local one that will fluctuate between the wake_up
and the actual thread being scheduled to run
2) The actual condition you need to check for might not be the same as
the one that triggered the wake_up. This is what the SCSI problem was.
3) There might genuinely be n triggers of the event. With a semaphore,
if we get three up()'s before the waiting thread is schedules, it will
process three times. With wait_event, the other two will be lost.
Thus, to effect this replacement, you need a thorough audit of what is
usually pretty non-trivial code.
What's the overriding reason for doing this? the pain doesn't look to
be worth the gain (since I don't see any gain).
James
prev parent reply other threads:[~2004-10-25 0:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 19:29 [PATCH] SCSI: Replace semaphores with wait_even Thomas Gleixner
2004-10-24 19:57 ` James Bottomley
2004-10-24 20:06 ` Thomas Gleixner
2004-10-24 23:01 ` James Bottomley
2004-10-24 23:06 ` Ingo Molnar
2004-10-25 0:02 ` James Bottomley [this message]
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=1098662552.10824.369.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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).