[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0805250937430.22587@gandalf.stny.rr.com>
Date: Sun, 25 May 2008 09:40:13 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
linux-rt-users <linux-rt-users@...r.kernel.org>, akpm@...l.org,
Ingo Molnar <mingo@...e.hu>,
Clark Williams <clark.williams@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
Gregory Haskins <ghaskins@...ell.com>, Andi Kleen <ak@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86: enable preemption in delay
On Sun, 25 May 2008, Alan Cox wrote:
> > And what happens when we have 10GHz boxes that can do migration in 1us,
> > and the delay that is asked for is 2us. We can return early. I don't like
> > to place assumptions of this kind that can hurt with future hardware
> > enhancements.
>
> Then in the hypothetical future you fix it, and for now its clearly
No, I'm saying that we don't need to account for the migrate. It will
only make the delay longer, and if the code was preemptible, that delay
is not guaranteed to be that long anyway.
> documented. Th preempt botch in the current tree breaks all sorts of
> existing real world setups so needs to go. (and we have people who do
> stuff like mdelay(150);
My updated patch takes Thomas's patch into consideration. There's no need
to put on limited timeouts due to migration.
-- Steve
--
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