Re: [patch] scheduler cache affinity improvement for 2.4 kernels

[Mike Fedyk]

On Thu, Nov 08, 2001 at 11:13:30AM -0800, Davide Libenzi wrote:
> On Thu, 8 Nov 2001, Ingo Molnar wrote:
> 
> >
> > On Thu, 8 Nov 2001, Davide Libenzi wrote:
> >
> > > It sets the time ( in jiffies ) at which the process won't have any
> > > more scheduling advantage.
> >
> > (sorry, it indeed makes sense, since sched_jtime is on the order of
> > jiffies.)
> >
> > > > and your patch adds a scheduling advantage to processes with more cache
> > > > footprint, which is the completely opposite of what we want.
> > >
> > > It is exactly what we want indeed :
> >
> > if this is what is done by your patch, then we do not want to do this.
> > My patch does not give an advantage of CPU-intensive processes over that
> > of eg. 'vi'.
> 
> If A & B are CPU hog processes and E is the editor ( low level keventd )
> you do want to avoid priority inversion between A and B when E kicks in.
> Really IO bound tasks accumulates dynamic priority inside the recalc loop
> and this is sufficent to win over this kind of "advantage" given to CPU
> hog tasks.
> My approach make also more "expensive" the preemption goodness to move
> tasks between CPUs.
> I'll take a closer look at your patch anyway.
> 

Conceptually, both patches are compatible.

Whether they are technically is for someone else to say...

Ingo's patch in effect lowers the number of jiffies taken per second in the
scheduler (by making each task use several jiffies).

Davide's patch can take the default scheduler (even Ingo's enhanced
scheduler) and make it per processor, with his extra layer of scheduling
between individual processors.

I think that together, they both win.  Davide's patch keeps a task from
switching CPUs very often, and Ingo's patch will make each task on each CPU
use the cache to the best extent for that task.

It remains to be proven whether the coarser scheduling approach (Ingo's) will
actually help when looking at cache properties....  When each task takes a
longer time slice, that allows the other tasks to be flushed out of the
caches during that time.  When the next task comes back in, it will have to
re-populate the cache again.  And the same for the next and etc...

Mike