Date: Sat, 2 Jun 2007 15:35:48 -0500 From: Larry Rosenman <ler@lerctr.org> To: Kris Kennaway <kris@obsecurity.org> Cc: takawata@freeBSD.org, Dag-Erling Sm??rgrav <des@des.no>, current@freeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Nate Lawson <nate@root.org> Subject: Re: HPET vs other timers Message-ID: <F6CB4D42-1E45-4580-A49E-A530ABABEC48@lerctr.org> In-Reply-To: <20070602200430.GA1846@rot13.obsecurity.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> <20070602200430.GA1846@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 2, 2007, at 3:04 PM, Kris Kennaway wrote: > 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. > I have a Intel 5000P based system that is picking HPET. How can I profile it for y'all? (The system is running -CURRENT from yesterday, and I can also give SSH access to some folks if they want). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6CB4D42-1E45-4580-A49E-A530ABABEC48>