[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1009141149380.2416@localhost6.localdomain6>
Date: Tue, 14 Sep 2010 11:52:57 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Vasily Khoruzhick <anarsoul@...il.com>
cc: Venkatesh Pallipadi <venki@...gle.com>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: Interrupt latency on some 945GM platforms
On Tue, 14 Sep 2010, Vasily Khoruzhick wrote:
> В сообщении от 14 of September 2010 03:55:32 автор Venkatesh Pallipadi
> написал:
>
> > Whats the clockevent in this case ("Tick Device" section of
> > /proc/timer_list). clocksource= option only changes the clocksource used
> > to maintain
> > timeofday. But, timer interrupt (clockevent) source will not change.
> > Wondering how just the clocksource change is making the diff here..
> >
> > Also, if clocksource tsc has a higher rating than HPET. The reason
> > HPET is getting used as clocksource in the first place seems to be due
> > to TSC is not a dependable clocksource on this platform (may be it
> > stops in C3). So, I am not sure forcing it to tsc will be a good
> > thing. May be clocksource=acpi_pm is a better thing to try.
> >
> > Thanks,
> > Venki
>
> I investigated it a bit and found out that single nohz=off option helps. Just
> changing clocksource doesn't help, but it works smoothly with any clocksource
> with nohz=off. So, it seems that something wrong with intel driver while
> system is in tickless mode.
Can you try with NOHZ enabled and the following on the kernel command line:
processor.max_cstate=1
Make sure that CONFIG_ACPI_PROCESSOR is set to "y" and not to "m"
If that works, then try
processor.max_cstate=2
Thanks,
tglx
Powered by blists - more mailing lists