> I've read the patch and think you're right about this one.
> Under normal loads 2.2.8 will have no problems at all except
> possibly the fact that it calls reschedule_idle() twice on
> most reschedules [...]
what do you mean? We call reschedule_idle() only when a process 1) gets
runnable 2) gets scheduled away (but is still runnable). These are two
different situations.
> [...] and the fact that the kernel still recalculates
> the priority of _all_ processes as soon as one process runs
> out of it's time slice.
this recalculation argument is a complete red herring. I've explained this
earlier too: the number of recalculations happens at a _constant
frequency_, with the additional mechanizm that there are less
recalculations if there are more CPU-bound processes. The goal is to have
tasks' increase their 'dynamic priority' even if they are not on the
runqueue. So any architectural change that concentrates on removing these
recalculations is seriously misguided.
>
> > > [...] and to
> > > reduce the CPU time used by niced tasks.
> >
> > this can be achieved by increasing (or changing) the scale of
> > priorities. (this can be done seemlessly)
>
> More importantly, it can be done without an increase in
> the scheduling overhead and with removal of the current
> process recalculation ritual.
>
> It will increase SMP scalability of the scheduler, allow
> for a wider priority scale and maybe even decrease scheduler
> overhead (I'm not sure about the last one being measurable
> though)...
>
> cheers,
>
> Rik -- Open Source: you deserve to be in control of your data.
> +-------------------------------------------------------------------+
> | Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
> | Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
> | Nederlandse Linux documentatie: http://www.nl.linux.org/ |
> +-------------------------------------------------------------------+
>
-
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/