[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070801175004.GA17936@elte.hu>
Date: Wed, 1 Aug 2007 19:50:04 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>,
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
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 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*.
but that does not appear to be the case, the debug info i got from Roman
includes the following boot options:
Kernel command line: auto BOOT_IMAGE=2.6.23-rc1-git9 ro root=306
there's no "notsc" option there.
Andi's theory cannot be true either, Roman's debug info also shows this
/proc/<PID>/sched data:
clock-delta : 95
that means that sched_clock() is in high-res mode, the TSC is alive and
kicking and a sched_clock() call took 95 nanoseconds.
Roman, could you please help us with this mystery?
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