public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Alistair John Strachan <alistair@devzero.co.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	mingo@elte.hu, hpa@zytor.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: enable hpet=force for AMD SB400
Date: Fri, 4 Jul 2008 20:55:42 +0200	[thread overview]
Message-ID: <20080704185542.GC21102@alberich.amd.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0805111059190.3197@apollo.tec.linutronix.de>

On Sun, May 11, 2008 at 11:03:16AM +0200, Thomas Gleixner wrote:
> On Sun, 11 May 2008, Alistair John Strachan wrote:
> > either the Intel quirk should be consistent with the hpet=force usage, 
> > or "known correct" HPET overrides should just always be applied.
> 
> That's what we do. We have "known correct" for Intel and those which
> work on the patch submitters box w/o confirmation of the
> correctness. I guess the SB400 one can move into the "is correct"
> category, Andreas ???

Seems that I was too quick with the submission of my patch.  I have
done some testing in the past few weeks and there are severe problems
with HPET on IXP400/IXP450 which I was not aware of before.

The HPET on that chipset is usually not activated because it is not
fully compliant to the HPET spec. Using HPET on older revisions of
that chipset does not make sense at all.

For newer chipset revisions I found a working configuration, but ...

The only reliable configuration that worked in periodic _and_ one-shot
mode was to configure it such that HPET interrupt is delivered to INT2
of IOAPIC.

This means to force usage of HPET on IXP400/IXP450 needs a "manual"
IRQ0/INT2 override and some more chipset configuration to ensure that
the HPET interrupt is routed to INT2 of IOAPIC.

So this all is a big mess. And it probably explains why most (almost
all?) IXP400/IXP450 based systems do not provide an ACPI HPET table.

Said that, the question is, why would it still be worthwhile to force
usage of HPET on such systems. This is what sprang to my mind:

(1) availability of /dev/hpet for users

(2) faster timer programming

    From what I've seen setting up a timer in Linux' one-shot mode on
    SB400 (and also on SB600) is more than twice as fast when using
    HPET in comparison to PIT (on average).

(3) faster clocksource than acpi_pm

    E.g. on dual core K8 systems Linux cannot use TSC as clocksource.
    So usually it falls back to acpi_pm. IMHO access to HPET main
    counter is faster than using acpi_pm as clocksource. But I didn't
    determine exact numbers fot that.

(4) Viewer interrupts when Linux is running in NOHZ mode

    ... on systems where AMD C1E is enabled. If there is no HPET the
    Kernel falls back to PIT, but that one as just a 16-bit counter and
    overflows at least every 0.055 seconds.

(5) HPET is more accurate than PIT - as it has a smaller minimum delta
    (Examples for minimum delta according to /proc/timer_list are
    HPET:  3352 ns, PIT: 12571 ns.)

So far I have thought that (2) and (4) were helpful to save power on
my Turion X2 Laptop in NOHZ mode. But I recently did some evaluation
of that and it's rather negligible.

So there remain (1), (3) and (5) and I really tend to ignore HPET on
SB400 in the future. ;-(

It might even be worthwhile to disable it on systems where it's
advertised by an ACPI HPET table.

Any opinion about that last point?

In any case, please revert commit e8aa4667baf74dfd85fbaab86861465acb811085
The quirk is useless without doing more chipset an IOAPIC
configuration to ensure proper interrupt routing.


Thanks,

Andreas



      parent reply	other threads:[~2008-07-04 18:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-09  9:49 [PATCH] x86: enable hpet=force for AMD SB400 Andreas Herrmann
2008-05-09 23:37 ` Andrew Morton
2008-05-09 23:42   ` Thomas Gleixner
2008-05-09 23:55     ` Andrew Morton
2008-05-10  0:02       ` Thomas Gleixner
2008-05-10 20:40       ` Thomas Gleixner
2008-05-11  3:02       ` Alistair John Strachan
2008-05-11  9:03         ` Thomas Gleixner
2008-06-24 16:00           ` Andreas Herrmann
2008-07-04 18:55           ` Andreas Herrmann [this message]

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=20080704185542.GC21102@alberich.amd.com \
    --to=andreas.herrmann3@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alistair@devzero.co.uk \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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