On Fri, 16 Nov 2007 07:13:32 +0100 Ingo Molnar <[email protected]> wrote:
>
> * Andrew Morton <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
