Date: Sat, 2 Jun 2007 16:04:30 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Nate Lawson <nate@root.org> Cc: takawata@freeBSD.org, Dag-Erling Sm??rgrav <des@des.no>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: HPET vs other timers Message-ID: <20070602200430.GA1846@rot13.obsecurity.org> In-Reply-To: <4661CA8F.8040000@root.org> References: <2792.1179764955@critter.freebsd.dk> <86zm3y9hg5.fsf@dwp.des.no> <4651E484.1010204@root.org> <20070602194151.GA1604@rot13.obsecurity.org> <4661CA8F.8040000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 02, 2007 at 12:52:47PM -0700, Nate Lawson wrote: > Kris Kennaway wrote: > > 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? > > It's not the workload, it's the system. These timers are provided by > the chipset and enabled by the BIOS and so the behavior is > system-dependent. Of course, it shouldn't be that way and this should > always be the fastest timer but when it comes to the BIOS, major > mistakes and weird behavior are always expected. > > HPET will be the main timer for Vista and is faster on at least one > system according to this study. > http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx > > More info: > http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/30232032/30232368/ShowThread.aspx > > Perhaps we should implement profiling of all timecounters instead of a > hard-coded quality value? That might be a good idea. Failing that, I'd say that we at least need some convincing evidence that HPET is indeed fast on a suitably large subset of existing systems. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070602200430.GA1846>