On Wed, 9 Jun 1999, Emil Briggs wrote:
> There are a few other features that could be helpful in some situations.
>
> 1. Gang scheduling of kernel mode threads is important on large SMP
> machines. [...]
we have gang scheduling ... does no-one read source-code anymore? :)
/*
* If there is a dependency between p1 and p2,
* don't be too eager to go into the slow schedule.
* In particular, if p1 and p2 both want the kernel
* lock, there is no point in trying to make them
* extremely parallel..
*
* (No lock - lock_depth < 0)
*
* There are two additional metrics here:
*
* first, a 'cutoff' interval, currently 0-200 usecs on
* x86 CPUs, depending on the size of the 'SMP-local cache'.
* If the current process has longer average timeslices than
* this, then we utilize the idle CPU.
*
* second, if the wakeup comes from a process context,
* then the two processes are 'related'. (they form a
* 'gang')
*
*
* An idle CPU is almost always a bad thing, thus we skip
* the idle-CPU utilization only if both these conditions
* are true. (ie. a 'process-gang' rescheduling with rather
* high frequency should stay on the same CPU).
*
* [We can switch to something more finegrained in 2.3.]
*
* do not 'guess' if the to-be-scheduled task is RT.
*/
our gang scheduling is currently only limited to distribute the effect of
the 'big kernel lock' better, but the concept is there and can be applied
when massively parallel SMP boxes become available.
> 2. I have sometimes wanted to use FIFO or RR scheduling within a
> set of threads -- I'm not talking about actual realtime scheduling
> against all process's on the system but only within a group of threads.
what particular effect do you want to achieve? Note that the current
scheduler does prefer to switch within the same 'thread group' (or rather,
threads belonging to the same VM object) to get better TLB (and other
cache) locality - although this is not very aggressive right now. (mainly
because no-one has yet shown an application that could benefit from
anything different)
-- mingo
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
