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/