[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160082716.9060.105.camel@localhost.localdomain>
Date: Thu, 05 Oct 2006 23:11:56 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <ak@...e.de>
Cc: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
John Stultz <johnstul@...ibm.com>,
Valdis Kletnieks <valdis.kletnieks@...edu>,
Arjan van de Ven <arjan@...radead.org>,
Dave Jones <davej@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Jim Gettys <jg@...top.org>,
Roman Zippel <zippel@...ux-m68k.org>, akpm@...l.org
Subject: Re: [patch 00/22] high resolution timers / dynamic ticks - V3
On Thu, 2006-10-05 at 22:57 +0200, Andi Kleen wrote:
> > ah, that's still the VAIO, right? Do you get a 'slow' LOC count on
> > /proc/interrupts even on a stock kernel? If yes then that's a
> > fundamentally sick local APIC timer interrupt. Stock kernel should show
> > sickness too, if for example you boot an SMP kernel on it - can you
> > confirm that? (the UP-IOAPIC only relies for profiling on the lapic
> > timer, so there the only sickness you should see on the stock kernel is
> > a non-working readprofile)
>
> When I was hacking on my old noidletick patch I ran into this
> problem on several machines too.
>
> But usually the problem wasn't that it was too slow, but that
> it completely stopped in C2 or deeper. I don't think there
> is a way to work around that except for not using C2 or deeper
> (not an option) or using a different timer source.
>
> If that is true then hitting space lots of time will make it
> go faster.
If that's the case we can even autodetect it and stay with PIT and
ignore lapic all the way.
tglx
-
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