lkml.org 
[lkml]   [1998]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH *] scheduler bigpatch (test results)
On Wed, 21 Oct 1998 19:06:56 +0200, Kurt Garloff wrote:

> Looking at your code, I think you did mean it: sched.c:581:
> else /* SCHED_IDLE, long slices */
> p->counter += 499;

I don't get it, just *how* did the author of the patch think this would work
correctly???

Once a process gets scheduled, the kernel will let it finish its slice
without ever interrupting it, unless it needs to sleep. Which is obviously
not the case with something like the rc5des which is doing pure CPU work.
Whenever everything is blocked, the SCHED_IDLE process will be scheduled
and then *nothing* else will run on the system until that process eats up
its slice. Make it a 1 minute long slice and you'll sit idle for 1 minute
in front of your computer waiting for the echo of your characters.

This is why I consider the SCHED_IDLE patch in its current incarnation to
be fundamentally broken. Yes, you can change the slice back to 25, but then
you're just fooling yourself, the SCHED_IDLE process will still be eating
CPU time even when other processes are competing for the CPU. It won't be
as bad as with long slices, but it will happen nevertheless.

If you want a real SCHED_IDLE scheduling class, you need to deschedule the
SCHED_IDLE process _right away_, as soon as something else pops up onto the
run queue. And even that will not be perfect, it will just make it have
1 jiffy granularity.

I hope this is what the latest patch is doing -- I haven't checked.


Ion

--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.119 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site