On Sat, Jul 06, 2002 at 08:08:11PM +0200, Guillaume Cottenceau wrote:
> example, when you play a realtime game, any process requesting
> CPU time, though put at +19, makes a big difference. 

Yes, the current linux scheduler has all nice levels too much close.

This is why I use a patch from Rik van Riel:

"... a fairly small and non-intrusive patch that widens the scale of
nice levels. That is, higher nice levels get far less CPU and the
lower nice levels actually start meaning something:"

http://www.surriel.com/patches/2.4/2.4.3ac4-largenice

This patch is a few-liner and should be very safe (look at it).
I already recommended this patch earlier but it was too close before
MDK 8.2 ... I recommend this for inclusion into MDK kernels.

Largenice patch should help with CPU fairness (now +19 setiathome
takes almost no desktop performance), but still there could be some
low priority task which trashes the disc/cache. This could be a little
better with sched O(1) from Ingo Molnar (which is now in 2.5.x),
because it is generally better (more clever) scheduler and runs +19
jobs as "batch jobs" which means that it gives them longer
timeslices but not so often. (This patch is also backported to 2.4 by
Robert Love - http://lwn.net/Articles/4079/ )

Andrew Morton wrote some patch which also helps increase
interractivity especially on desktops - it lowers latency of readers
when there are some heavy-writers.

http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre5/read-latency2.patch

See also low latency patches:
http://www.zip.com.au/~akpm/linux/schedlat.html

(note: mini low latency patches are already included in 2.4.18mdk)


> I don't know what are the exact figures, but I guess it's impossible
> to have a process eat less than 10-15% of the CPU even if you nice
> it to the extreme.

Large nice patch make's it more fair:

        Nice    0    5   10   15   19
        %CPU  100   56   25    6    1        

If it still about "slocate slowes performance" then it's not a CPU
issue but more about read/write latency (which should be much better
with Andrew Morton's read-latency patch).

-- 
         Martin Mačok                 http://underground.cz/
   [EMAIL PROTECTED]        http://Xtrmntr.org/ORBman/

Reply via email to