[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080511144611.GV19219@parisc-linux.org>
Date: Sun, 11 May 2008 08:46:11 -0600
From: Matthew Wilcox <matthew@....cx>
To: Ingo Molnar <mingo@...e.hu>
Cc: Sven Wegener <sven.wegener@...aler.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Andi Kleen <andi@...stfloor.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] scheduler fixes
On Sun, May 11, 2008 at 04:32:27PM +0200, Ingo Molnar wrote:
>
> * Matthew Wilcox <matthew@....cx> wrote:
>
> > > the gain is rather obvious: two parallel up()s (or just up()s which
> > > come close enough after each other) will wake up two tasks in
> > > parallel. With your patch, the first guy wakes up and then it wakes
> > > up the second guy. I.e. your patch serializes the wakeup chain, mine
> > > keeps it parallel.
> >
> > Yup. I explained why that's actually beneficial in an earlier email.
>
> but the problem is that by serializing the wakeup chains naively you
> introduced a more than 50% AIM7 performance regression.
That's a different issue. The AIM7 regression is to do with whether a
task that is currently running and hits a semaphore that has no current
holder but someone else waiting should be allowed to jump the queue.
No argument there; performance trumps theoretical fairness.
This issue is whether multiple sleepers should be woken up all-at-once
or one-at-a-time. Here, you seem to be arguing for theoretical fairness
to trump performance.
(Let's be quite clear; this issue affects *only* multiple
sleepers and multiple wakes given to those sleepers. ie
semaphores-being-used-as-completions and true counting semaphores).
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists