From owner-freebsd-current@FreeBSD.ORG Sat Jun 2 20:59:15 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 09C8416A46C; Sat, 2 Jun 2007 20:59:15 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id CAE3C13C46C; Sat, 2 Jun 2007 20:59:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from [216.143.72.2] (port=33726 helo=[10.111.112.36]) by thebighonker.lerctr.org with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HuaKH-000Kzu-KN; Sat, 02 Jun 2007 15:35:58 -0500 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> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Larry Rosenman Date: Sat, 2 Jun 2007 15:35:48 -0500 To: Kris Kennaway X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, DKIM_POLICY_SIGNSOME=0.001, HTML_MESSAGE=0.001 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, DKIM_POLICY_SIGNSOME=0.001, HTML_MESSAGE=0.001 DomainKey-Status: no signature Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: takawata@freeBSD.org, Dag-Erling Sm??rgrav , current@freeBSD.org, Poul-Henning Kamp , Nate Lawson 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:59:15 -0000 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" 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. > 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