From: Andi Kleen <ak@suse.de>
To: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
mingo@elte.hu, linux-kernel <linux-kernel@vger.kernel.org>,
Rajesh Shah <rajesh.shah@intel.com>,
John Stultz <johnstul@us.ibm.com>, Andi Kleen <ak@suse.de>,
Asit K Mallick <asit.k.mallick@intel.com>
Subject: Re: [RFC][PATCH] i386 x86-64 Eliminate Local APIC timer interrupt
Date: Mon, 2 May 2005 18:38:21 +0200 [thread overview]
Message-ID: <20050502163821.GE7342@wotan.suse.de> (raw)
In-Reply-To: <20050429172605.A23722@unix-os.sc.intel.com>
On Fri, Apr 29, 2005 at 05:26:05PM -0700, Venkatesh Pallipadi wrote:
>
> Background:
> Local APIC timer stops functioning when CPU is in C3 state. As a
> result the local APIC timer interrupt will fire at uncertain times, depending
> on how long we spend in C3 state. And this has two side effects
> * Idle balancing will not happen as we expect it to.
> * Kernel statistics for idle time will not be proper (as we get less LAPIC
> interrupts when we are idle). This can result in confusing other parts of
> kernel (like ondemand cpufreq governor) which depends on this idle stats.
This is absolutely incompatible to no timer tick in IDLE - at least
my implementation that allows to keep all CPUs indepently in idle,
not require all CPUs to be idle to turn off the timers.
I had hoped that the hardware was clever enough to keep the
APIC timers working on SMP systems.
This is very unfortunate :-(( It means you will always
waste a lot of power on a partially idle system, because
you cannot keep individual CPUs sleeping for a longer time.
I ran into the problem on AMD systems with C2 state - in
my initial implementation there was only the APIC timer for
any time keeping because it is cheaper to reprogram and
there are a lot of chipsets which miss HPET - and on the
BP only the APIC timer was ticking at all, which did not
work very well. This was avoided by using
PIT/HPET on the BP again. But on SMP systems there is not
much choice on the APs.
> it simplifies things and will have other advantages:
> * Should help dynamick tick as one has to change only global timer interrupt
> freq with varying jiffies.
Huh? On contrary it completely kills really SMP aware dynamic tick
implementations.
I would really prefer to find some other way to solve this
Perhaps if we have enough timer sources in HPET we can use the 3-4
HPET timers on different CPUs. That would work on upto 4 socket
systems (sibling/dual core can be ignored I guess because for
power management purposes they dont really exist)
This would be a problem for the few applications that use HPET
from user space for application timers, but I think power saving
is more important than them or they can disable dynamic tick.
It is a big mess. I begin to envy the PPC guys who
actually have usable per CPU timers.
-Andi
next prev parent reply other threads:[~2005-05-02 16:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-30 0:26 Venkatesh Pallipadi
2005-04-30 0:46 ` Zwane Mwaikambo
2005-04-30 0:58 ` Zwane Mwaikambo
2005-04-30 1:13 ` Zwane Mwaikambo
2005-04-30 2:32 ` Andrew Morton
2005-05-02 16:38 ` Andi Kleen [this message]
2005-05-02 17:16 ` Venkatesh Pallipadi
2005-05-02 19:08 ` Andi Kleen
2005-05-02 20:27 ` Venkatesh Pallipadi
2005-05-03 14:17 ` Andi Kleen
2005-05-05 5:33 ` Len Brown
2005-05-05 12:19 ` Andi Kleen
2005-05-11 18:12 ` Tony Lindgren
2005-05-05 20:45 ` George Anzinger
2005-04-30 2:43 Pallipadi, Venkatesh
2005-05-05 4:16 ` Len Brown
2005-05-05 12:03 ` Andi Kleen
2005-05-05 12:32 ` Maciej W. Rozycki
2005-04-30 2:55 Pallipadi, Venkatesh
2005-04-30 3:06 ` Andrew Morton
2005-05-02 21:19 ` Pavel Machek
2005-04-30 19:40 Protasevich, Natalie
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=20050502163821.GE7342@wotan.suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=asit.k.mallick@intel.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rajesh.shah@intel.com \
--cc=torvalds@osdl.org \
--cc=venkatesh.pallipadi@intel.com \
/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
Powered by JetHome