Date: Mon, 21 May 2007 11:27:16 -0700 From: Nate Lawson <nate@root.org> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no> Cc: takawata@freeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: HPET vs other timers Message-ID: <4651E484.1010204@root.org> In-Reply-To: <86zm3y9hg5.fsf@dwp.des.no> References: <2792.1179764955@critter.freebsd.dk> <86zm3y9hg5.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4651E484.1010204>