[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071116061332.GF16273@elte.hu>
Date: Fri, 16 Nov 2007 07:13:32 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Arjan van de Ven <arjan@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: x86: disable preemption in delay_tsc()
* Andrew Morton <akpm@...ux-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()? That would be a sufficient solution and would
avoid all the calibration and per-cpu-ness problems.
Ingo
-
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