From owner-freebsd-hackers Thu Dec 5 1:59:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A162137B401 for ; Thu, 5 Dec 2002 01:59:50 -0800 (PST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3D443E4A for ; Thu, 5 Dec 2002 01:59:50 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0020.cvx40-bradley.dialup.earthlink.net ([216.244.42.20] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18JsnF-0005qu-00; Thu, 05 Dec 2002 01:59:41 -0800 Message-ID: <3DEF2340.C4AEED1A@mindspring.com> Date: Thu, 05 Dec 2002 01:58:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stijn Hoop Cc: hackers@freebsd.org Subject: Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle] References: <20021202151816.GJ83264@pcwin002.win.tue.nl> <20021202114019.R31106-100000@patrocles.silby.com> <20021204113154.GA205@pcwin002.win.tue.nl> <3DEE4418.868B4936@mindspring.com> <20021204191125.GG52541@pcwin002.win.tue.nl> <3DEE58C6.19ACF59C@mindspring.com> <20021205085604.GB56010@pcwin002.win.tue.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stijn Hoop wrote: > > It's a flawed benchmark. > > I'd argue it isn't flawed for the measuring it is supposed to do - namely > the overhead for the various _sleep functions. Care to tell me why it is > flawed according to you? Because it measures the API one way, but the code uses it another. The results you get are not predictive of the code that you are going to be running. > > The hardclock rate gets boosted in the kernel under certain usage > > conditions, among them being using the PC speaker driver. I > > believe there is an interface available that you could abuse to > > raise it the same way. Far be it for sotware to know about the > > hardware it's running on, though... 8-). > > That sounds.... gross... :) Well, really, something that requires RT performance should be in the kernel. That's why we put interrupt handlers there. 8-). Probably the place to do this is in the POSIX RT scheduling; if the RT scheduling is active (meaning a process has called it, and that process is still running), it's probably a reasonable thing to crank up the Hz. This would make it self-adjusting, and also self-healing, so that you could safely degrade the overall system performance by intentionally running your application, but not otherwise. Note that if this were implemented, it would mean your benchmark is still broken, because it doesn't call the necessary interfaces. Another alternative would be a nanosleep call with an argument below a certain value. I would hesitate to do it that way, though, since I think that it ought to take a priviledged program to do the evil deed, given the impact on the rest of the system. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message