Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Dec 2002 01:58:24 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Stijn Hoop <stijn@win.tue.nl>
Cc:        hackers@freebsd.org
Subject:   Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Message-ID:  <3DEF2340.C4AEED1A@mindspring.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEF2340.C4AEED1A>