[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071115194116.12c7a0f6@laptopd505.fenrus.org>
Date: Thu, 15 Nov 2007 19:41:16 -0800
From: Arjan van de Ven <arjan@...radead.org>
To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: x86: disable preemption in delay_tsc()
On Thu, 15 Nov 2007 04:00:47 GMT
Linux Kernel Mailing List <linux-kernel@...r.kernel.org> wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf
> Commit: 35d5d08a085c56f153458c3f5d8ce24123617faf Parent:
> 7eea436433b7b18045f272562e256976f593f7c0 Author: Andrew Morton
> <akpm@...ux-foundation.org> AuthorDate: Wed Nov 14 17:00:41 2007 -0800
> Committer: Linus Torvalds <torvalds@...dy.linux-foundation.org>
> CommitDate: Wed Nov 14 18:45:44 2007 -0800
>
> 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.
--
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
-
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