Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Jun 2007 15:41:51 -0400
From:      Kris Kennaway <kris@obsecurity.org>
To:        Nate Lawson <nate@root.org>
Cc:        Dag-Erling Sm??rgrav <des@des.no>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Kris Kennaway <kris@obsecurity.org>, current@freeBSD.org, takawata@freeBSD.org
Subject:   Re: HPET vs other timers
Message-ID:  <20070602194151.GA1604@rot13.obsecurity.org>
In-Reply-To: <4651E484.1010204@root.org>
References:  <2792.1179764955@critter.freebsd.dk> <86zm3y9hg5.fsf@dwp.des.no> <4651E484.1010204@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 21, 2007 at 11:27:16AM -0700, Nate Lawson wrote:
> Dag-Erling Sm??rgrav wrote:
> > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
> >> Dag-Erling Sm??rgrav <des@des.no> writes:
> >>> "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
> >>>> I can't rememember who raised the quality of it recently, CVS will
> >>>> know.  I was sceptical, because I also have systems where HPET is
> >>>> slow.
> >>> I did, with your approval, almost a year ago.
> >> Yes, I said "try it" or something of the sort.
> > 
> > For the record, I ran with HPET timers the entire time from HPET support
> > was first committed until I finally committed that patch - about ten
> > months - so I did test it to the best of my ability.
> > 
> > DES
> 
> Let's keep this technical.  I'm fine with bumping HPET to below ACPI
> timer if the hw turns out to be this much slower.
> 
> Anyone able to speculate why though?  HPET only reads 32 bits from a
> memory mapped region.  No locking or other requirements.  ACPI_timer
> does multiple IO ops, which according to bde@ are much slower than
> memory reads.  So unless something from the chipset is stopping the
> processor (SMI?) when it reads from this region, I have a hard time
> seeing why it's slower.

I don't know what the cause is, only that it is empirically the
slowest of all the timers in this workload.  Can you provide
supporting evidence that it is fact faster than all the alternatives
in other workloads?

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070602194151.GA1604>