Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Len Brown]

On Monday 29 January 2007 01:55, Ingo Molnar wrote:
> 
> * Len Brown <lenb@kernel.org> wrote:
> 
> > > -     if(cx->type == ACPI_STATE_C3 ||
> > > -        boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> > > +	if (cx->type >= ACPI_STATE_C2)
> > >  		pr->power.timer_broadcast_on_state = state;
> > > -		return;
> > > -	}
> > 
> > This is going to be a problem. Do you have a pointer to an Intel box 
> > who's LAPIC timer stops in C2?
> 
> btw., why is it going to be a problem? It basically activates the 
> fall-back-to-PIT-broadcasting workaround for all C2-capable systems. 
> Given that most modern laptops do C3, and C3 definitely turns off the 
> lapic, is this a big issue? I'd rather default to the more conservative 
> behavior on C2 too.

Why don't we activate the fall-back-to-PIT-broadcasting always --
even for systems which have just C1?

The answer to that question is the same as the answer to the question you ask.

I don't think the above patch is conservative, AFAIK it is simply erroneous.

My understanding is that
1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
2. All existing Intel systems have a BROKEN LAPIC timer in C3.

If you've found a system that defies these rules, then I'm extremely
interested to know about it.

> note that with the new clockevents code the workaround can fall back not 
> just to the PIT but to hpet as well - if it's available. The T60 
> core2duo laptop i have does that for example. That gives much 
> higher-quality dynticks behavior. (the PIT is limited to a maximum of 27 
> msecs interval - resulting in a minimum rate of 37 timer irqs per 
> second)

The fact that the HPET can interrupt at a very high rate is moot
from a power management point of view.
If we are focusing on the region above O(40H) HZ, then we already
blew it from a power savings point of view, as the very deep C-states
will not save any power at high interrupt rates.

Another alternative would be for systems with C3 to fall-back to a
periodic tick scheme that we have today.  From a power point of view,
HZ=100 would be only a little bit worse than Windows HZ=64.
However, FC6 seems to have marched off an built with
HZ=1000 -- so we'd have some challenges with static HZ too...

-Len

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Thomas Gleixner]

On Mon, 2007-01-29 at 18:55 -0500, Len Brown wrote:
> My understanding is that
> 1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
> 2. All existing Intel systems have a BROKEN LAPIC timer in C3.
> 
> If you've found a system that defies these rules, then I'm extremely
> interested to know about it.

Ask akpm. His vaio has this problem since ages. As well as other Intel
based boxen. Yes, they have broken BIOSes ....

Adding a commandline option like "c2works" might be appropriate. This
would also keep TSC alive on C2, where we default to not use it when C2
is reached right now for the very same reason (break as few boxen as
possible). Say thanks to AMD for that invention.

> > note that with the new clockevents code the workaround can fall back not 
> > just to the PIT but to hpet as well - if it's available. The T60 
> > core2duo laptop i have does that for example. That gives much 
> > higher-quality dynticks behavior. (the PIT is limited to a maximum of 27 
> > msecs interval - resulting in a minimum rate of 37 timer irqs per 
> > second)
> 
> The fact that the HPET can interrupt at a very high rate is moot
> from a power management point of view.
> If we are focusing on the region above O(40H) HZ, then we already
> blew it from a power savings point of view, as the very deep C-states
> will not save any power at high interrupt rates.

You misunderstood. HPET is much better than PIT for dynticks, as the
maximum timeout with HPET is way longer than with PIT (PIT maximum is
27ms). We can idle sleep longer with HPET than with PIT.

> Another alternative would be for systems with C3 to fall-back to a
> periodic tick scheme that we have today.  From a power point of view,
> HZ=100 would be only a little bit worse than Windows HZ=64.
> However, FC6 seems to have marched off an built with
> HZ=1000 -- so we'd have some challenges with static HZ too...

With dyntick enabled kernels you get ~ HZ=37 as the worst case with PIT,
while we go down to ~4HZ with HPET / apic timer (as long as it works)

	tglx

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Mon, 2007-01-29 at 18:55 -0500, Len Brown wrote:
> > My understanding is that
> > 1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
> > 2. All existing Intel systems have a BROKEN LAPIC timer in C3.
> > 
> > If you've found a system that defies these rules, then I'm extremely
> > interested to know about it.
> 
> Ask akpm. His vaio has this problem since ages. As well as other Intel 
> based boxen. Yes, they have broken BIOSes ....

my HP nx9030 is one such box too. [ I sent the BIOS info - Len, did you 
get those? ]

	Ingo

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> > Another alternative would be for systems with C3 to fall-back to a
> > periodic tick scheme that we have today.  From a power point of view,
> > HZ=100 would be only a little bit worse than Windows HZ=64.
> > However, FC6 seems to have marched off an built with
> > HZ=1000 -- so we'd have some challenges with static HZ too...
> 
> With dyntick enabled kernels you get ~ HZ=37 as the worst case with 
> PIT, while we go down to ~4HZ with HPET / apic timer (as long as it 
> works)

s/worst case/best case

the lower we can make the timer irq rate on an idle system, the better. 
HPET allows us to go from 37 Hz down to 4 Hz.

	Ingo