[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708010924490.3582@woody.linux-foundation.org>
Date: Wed, 1 Aug 2007 09:27:47 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andi Kleen <andi@...stfloor.org>
cc: Ingo Molnar <mingo@...e.hu>, Roman Zippel <zippel@...ux-m68k.org>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: CFS review
On Wed, 1 Aug 2007, Andi Kleen wrote:
> Ingo Molnar <mingo@...e.hu> writes:
>
> > thanks. Just to make sure, while you said that your TSC was off on that
> > laptop, the bootup log of yours suggests a working TSC:
> >
> > Time: tsc clocksource has been installed.
>
> Standard kernels often disable the TSC later after running a bit
> with it (e.g. on any cpufreq change without p state invariant TSC)
I assume that what Roman hit was that he had explicitly disabled the TSC
because of TSC instability with the "notsc" kernel command line. Which
disabled is *entirely*.
That *used* to be the right thing to do, since the gettimeofday() logic
originally didn't know about TSC instability, and it just resulted in
somewhat flaky timekeeping.
These days, of course, we should notice it on our own, and just switch
away from the TSC as a reliable clock-source, but still allow it to be
used for the cases where absolute accuracy is not a big issue.
So I suspect that Roman - by virtue of being an old-timer - ends up having
a workaround for an old problem that isn't needed, and that in turn ends
up meaning that his scheduler clock also ends up using the really not very
good timer tick..
Linus
-
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