[H-GEN] Priorities

[Greg Black]

On 2003-06-08, Robert Brockway wrote:
> On Sat, 7 Jun 2003, Greg Black wrote:
> 
> > [1] This is true for BSD; I'd be surprised if it was not true
> >     for other systems, although I haven't bothered to check.
> 
> Without having UTSL or RTFM, I'm inclined to believe any modern unix would
> act this way.

That's my expectation too, but it's not based on proper
research.

> A bit of emperical evidence now - I run seti at home at nice 19 - ie, it is
> as nice as it can get.  My system is currently cpu bound (cpu 100%
> constantly) thanks to a cpu intensive app I'm running (which is running at
> system standard priority).  Seti at home is consistently pulling 10-12% of
> the cpu. This is a bit higher than I would have guessed.  This is on Linux
> 2.4.20 btw.
> 
> This has sparked my interesting, and I'll be delving deeper into the
> current algorithm used in Linux.  It would be interesting to compare to
> other unixen.

Part of the stuff you'll need to research is the accuracy of the
actual measurement.  The task of recording resource usage is in
itself prone to various bugs and infelicities -- things can get
into lock step with the measurement facility and so appear
either to take more time than they really do (if they're always
active at the time the sample is taken), or less time than they
really do (for the obvious alternate case).  Different systems
have taken different approaches to correcting these anomalies in
measurement, but it's not a sufficiently important problem for
those who write the code to expend the time to perfect it.

> Year ago (1.0.x, 1.2.x ?) I actually patched my kernel with an alternative
> scheduling algorithm.  Although the new scheduler reputed to be "fairer"
> with cpu time than the standard Linux scheduler of the day it was
> noticable slower.  I ran it for about 30 minutes and rebooted to my old
> kernel :)

I'd be unlikely even to try an alternate scheduler.  Knowing
that no scheduler is perfect, and that the solution to poor
scheduling (especially in these days of almost free hardware) is
simply to provide one machine per important process, I prefer to
just throw hardware at this kind of problem -- on the very rare
occasions when it matters.

Greg

-- 
Greg Black <gjb at gbch.net> <http://www.gbch.net/gjb.html>
GPG signed mail preferred; further information in headers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20030610/030a0c3d/attachment.sig>