public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	akpm@osdl.org, mm-commits@vger.kernel.org, ak@muc.de,
	johnstul@us.ibm.com, zippel@linux-m68k.org,
	linux-acpi@vger.kernel.org, asit.k.mallick@intel.com,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree
Date: Tue, 30 Jan 2007 01:12:55 +0100	[thread overview]
Message-ID: <1170115975.29240.111.camel@localhost.localdomain> (raw)
In-Reply-To: <200701291855.36352.lenb@kernel.org>

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



  reply	other threads:[~2007-01-30  0:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200701282247.l0SMl3rG005194@shell0.pdx.osdl.net>
     [not found] ` <200701282153.29132.lenb@kernel.org>
     [not found]   ` <20070129065540.GB23785@elte.hu>
2007-01-29 23:55     ` + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree Len Brown
2007-01-30  0:12       ` Thomas Gleixner [this message]
2007-01-30 20:31         ` Ingo Molnar
2007-01-30 20:34         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170115975.29240.111.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=asit.k.mallick@intel.com \
    --cc=johnstul@us.ibm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mm-commits@vger.kernel.org \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox