Messages in this thread | | | Date | Thu, 15 Nov 2007 23:08:59 -0800 | From | Andrew Morton <> | Subject | Re: x86: disable preemption in delay_tsc() |
| |
On Fri, 16 Nov 2007 07:13:32 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> > * Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > x86: disable preemption in delay_tsc() > > > > > > > > Marin Mitov points out that delay_tsc() can misbehave if it is > > > > preempted and rescheduled on a different CPU which has a skewed > > > > TSC. Fix it by disabling preemption. > > > > > > > > > > this worries me.. this appears to effectively disable preemption > > > during udelay() and mdelay() loops... which are very obvious latency > > > inducers. > > > > > > Now you can argue that if you're preemptible you should have used > > > msleep() and co, and I'll totally buy that. > > > > > > > > > Maybe we should just check if we're still on the same cpu or > > > something, or have a cheap way to pin a process to a cpu.... but > > > both are longer term solutions. > > > > Yes, we can do better. > > > > But this bug can cause very rare failures in probably a large number > > of device drivers on a minorty of machines. Ugly. So I felt it best > > to plug it fast while people think about more sophisticated fixes. > > how about using usleep() transparently if high-res timers are active and > we have !preempt_count()?
And CONFIG_PREEMPT, of course
> That would be a sufficient solution and would > avoid all the calibration and per-cpu-ness problems.
It sounds like it would work OK. What is the setup cost for a usleep? I'd have thought that code which does something like
while (i++ < 1000) { foo(); udelay(1); }
would take qiute a bit longer with such a change?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |