public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Eduard-Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: pharon@gmail.com, Rene Herman <rene.herman@keyaccess.nl>,
	"David P. Reed" <dpreed@reed.com>,
	Richard Harman <richard@richardharman.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
Date: Sun, 30 Dec 2007 15:42:17 +0100	[thread overview]
Message-ID: <p73ejd41bxy.fsf@bingen.suse.de> (raw)
In-Reply-To: <20071230121725.11d05099@linux360.ro> (Eduard-Gabriel Munteanu's message of "Sun\, 30 Dec 2007 12\:17\:25 +0200")

Eduard-Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>
> Other kernel developers, as discussed previously in this thread, are
> working on a HPET-driven dynticks (as opposed to the current
> LAPIC-driven one), but the change isn't that easy to make.

No, actually HPET based dyntick has been implemented for a long time
(as long as APIC based dyntick). APIC based dyntick is preferred 
because it is a little cheaper, but both are there.

The problem is just that many BIOSes don't tell the kernel about the
HPET location (even when the chipset supports it) because that wasn't
needed for older Windows versions.  And without the BIOS telling the
kernel HPET it doesn't know where it is and can't use it when
the APIC timer is not usable.

The ongoing work is to implement hpet=force code that knows
about various chipsets and reads their hardware registers directly
and then uses the HPET timer without BIOS support.

The reason it is still an option is that there used to be at least one
old chipset where forcing the HPET could trigger hardware bugs.

On the other hand it is expected that BIOS versions support Vista
also supply HPET, so that problem will hopefully get better.

> This way,
> dynticks and C1E could be both enabled and thus save more power.

I would not expect too much over a HZ=100 kernel on current AMD. 

C1e doesn't have too much latency on its own. iirc at least on current
AMD platforms sleeping for longer didn't make too much
difference. With HZ=250 it might be borderline, but I would not expect
miracles. It's probably only clearly a good idea if you're on a
HZ=1000 kernel or have applications that need very precise hrtimers (but that
might cost more power again because it'll cause more wakeups) 

Of course this can always change in future systems -- these are
just rules of thumb currently.

-Andi

  reply	other threads:[~2007-12-30 14:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-29 14:43 [PATCH] Option to disable AMD C1E (allows dynticks to work) David P. Reed
2007-12-29 22:28 ` Islam Amer
2007-12-30  0:35   ` Islam Amer
2007-12-30 12:57     ` Ingo Molnar
2007-12-30  1:38   ` Rene Herman
2007-12-30  1:49     ` Islam Amer
2007-12-30  3:24       ` Rene Herman
2007-12-30 10:17       ` Eduard-Gabriel Munteanu
2007-12-30 14:42         ` Andi Kleen [this message]
2007-12-30 21:12           ` Eduard-Gabriel Munteanu
2007-12-31  2:34             ` Andi Kleen
2007-12-30 20:57         ` Richard Harman
2007-12-30 21:18           ` Eduard-Gabriel Munteanu
2007-12-30 13:36             ` Richard Harman
2007-12-30 23:32               ` Eduard-Gabriel Munteanu
2007-12-31  0:30               ` David P. Reed
     [not found] <47754735.1050009@richardharman.com>
2007-12-29  7:52 ` Eduard-Gabriel Munteanu
2007-12-29  9:09   ` Richard Harman
2007-12-29 11:19     ` Eduard-Gabriel Munteanu
2007-12-29 11:46     ` Islam Amer
2007-12-30 20:45     ` Rene Herman
  -- strict thread matches above, loose matches on Subject: below --
2007-12-14  0:14 Mikhail Kshevetskiy
2007-12-13 22:47 Eduard-Gabriel Munteanu
2007-12-13 22:58 ` Johannes Weiner
2007-12-14 12:48   ` Eduard-Gabriel Munteanu
2007-12-18 15:43 ` Pavel Machek
2007-12-18 17:11   ` Eduard-Gabriel Munteanu
2007-12-13 22:44 Eduard-Gabriel Munteanu
2007-12-13 22:33 ` Andi Kleen
2007-12-14 12:39   ` Eduard-Gabriel Munteanu
2007-12-14 10:17     ` Andi Kleen
2007-12-14 13:41       ` Eduard-Gabriel Munteanu
2007-12-14 12:20         ` Andi Kleen
2007-12-14 16:01           ` Eduard-Gabriel Munteanu
2007-12-14 18:07             ` Thomas Gleixner
2007-12-14 18:12               ` Andi Kleen
2007-12-14 19:57                 ` Thomas Gleixner
2007-12-14 20:06                   ` Andi Kleen
2007-12-14 19:58                 ` Eduard-Gabriel Munteanu
2007-12-14 18:10             ` Andi Kleen
2007-12-14 19:53               ` Thomas Gleixner
2007-12-14 22:35       ` Chuck Ebbert
2007-12-15  0:10         ` Eduard-Gabriel Munteanu
2007-12-15 12:41         ` Andi Kleen

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=p73ejd41bxy.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=dpreed@reed.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pharon@gmail.com \
    --cc=rene.herman@keyaccess.nl \
    --cc=richard@richardharman.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