From owner-freebsd-current@FreeBSD.ORG Sat Jun 2 20:04:32 2007 Return-Path: X-Original-To: current@freeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0848B16A400; Sat, 2 Jun 2007 20:04:32 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E811513C465; Sat, 2 Jun 2007 20:04:31 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A05D11A3C1C; Sat, 2 Jun 2007 13:05:45 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 15FCF511D0; Sat, 2 Jun 2007 16:04:31 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id 003D0C204; Sat, 2 Jun 2007 16:04:30 -0400 (EDT) Date: Sat, 2 Jun 2007 16:04:30 -0400 From: Kris Kennaway To: Nate Lawson Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4661CA8F.8040000@root.org> User-Agent: Mutt/1.4.2.2i Cc: takawata@freeBSD.org, Dag-Erling Sm??rgrav , Poul-Henning Kamp , current@freeBSD.org, Kris Kennaway Subject: Re: HPET vs other timers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2007 20:04:32 -0000 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" writes: > >>>> Dag-Erling Sm??rgrav writes: > >>>>> "Poul-Henning Kamp" 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