[PATCH] 2.3.41 scheduler change

[Steve Underwood]

Rik van Riel wrote:

> Hi,
>
> since the biggest penalty with scheduling is the repopulation
> of the cache with (user) pages from the new process, I've
> written a scheduler patch for 2.3.41 that tries to optimise
> for that.
>
> The patch doesn't use p->counter for priority purposes, this
> means that we should incurr less cache misses in the following
> (quite common?) situation.
>
> - you have a number of cpus, N (N = 1, 2, whatever)
> - you have N+1 processes using a fair amount of CPU
> - you have vi, pine, mutt, whatever using very little CPU
>
> When you press a key in vi and the currently running runnable
> process gets descheduled, it will have a lower priority than
> the other process (because it's used part of its timeslice)
> and immediately after vi the _other_ running process gets
> scheduled. This could result in unneeded cache thrashing.
>
> My patch calculates a slower-moving priority so that short-term
> use of CPU (within one timeslice) doesn't influence priority.
> This means that the _same_ running process will be rescheduled
> after vi goes back to sleep, this should reduce cache thrashing
> and increase efficiency.
>
> I haven't done a lot of performance tests with this scheduler
> yet, but xmms seems to use about 20% less CPU with this patch
> than without ... however, this is on a dual pentium with shared
> L2 cache. I suspect that a dual celeron or Xeon will see the
> biggest benefits of this patch.
>
> I'm interested in any comments on and measurements on this patch.
> p->counter and p->priority have been changed into shorts because
> the short->int conversion most probably is much cheaper than an
> extra cache miss ... any numbers on this are very much welcome too.

I don't know if your decision criteria are optimal, but I am sure that this general strategy should yield real benefits.
Its what I was trying to skirt around in a posting a couple of days ago, but written too late at night it came out rather
muddled.

What you are doing is putting a price on a change of tasks trashing the cache which is analogous to the way scheduling
currently puts a price on moving a task between processors, and trashing the cache. Although the benefits won't be quite
as high as the processor affinity logic, this kind of task affinity logic should be quite beneficial. Anyone who thinks
processor affinity is a Good Thing, should consider this too.

Steve



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