reschedule_idle changes in ac kernels

reschedule_idle changes in ac kernels

[Mike Kravetz]

I just noticed the changes to reschedule_idle() in the 2.4.5-ac
kernel.  I suspect these are the changes made for:

o       Fix off by one on real time pre-emption in scheduler

I'm curious if anyone has ran any benchmarks before and after
applying this fix.

The reason I ask is that during the development of my multi-queue
scheduler, I 'accidently' changed reschedule_idle code to trigger
a preemption if preemption_goodness() was greater than 0, as
opposed to greater than 1.  I believe this is the same change made
to the ac kernel.  After this change, we saw a noticeable drop in
performance for some benchmarks.

The drop in performance I saw could have been the result of a
combination of the change, and my multi-queue scheduler.  However,
in any case aren't we now going to trigger more preemptions?

I understand that we need to make the fig to get the realtime
semantics correct,  but we also need to be aware of performance in
the non-realtime case.

-- 
Mike Kravetz                                 mkravetz@sequent.com
IBM Linux Technology Center

Re: reschedule_idle changes in ac kernels

[Nigel Gamble]

On Mon, 4 Jun 2001, Mike Kravetz wrote:
> I just noticed the changes to reschedule_idle() in the 2.4.5-ac
> kernel.  I suspect these are the changes made for:
> 
> o       Fix off by one on real time pre-emption in scheduler
> 
> I'm curious if anyone has ran any benchmarks before and after
> applying this fix.

I was running realtime benchmarks, which was how I found the bug.

> The reason I ask is that during the development of my multi-queue
> scheduler, I 'accidently' changed reschedule_idle code to trigger
> a preemption if preemption_goodness() was greater than 0, as
> opposed to greater than 1.  I believe this is the same change made
> to the ac kernel.  After this change, we saw a noticeable drop in
> performance for some benchmarks.
> 
> The drop in performance I saw could have been the result of a
> combination of the change, and my multi-queue scheduler.  However,
> in any case aren't we now going to trigger more preemptions?
> 
> I understand that we need to make the fig to get the realtime
> semantics correct,  but we also need to be aware of performance in
> the non-realtime case.

The realtime bug was caused by whoever decided, sometime in 2.4, that
the result of preemption_goodness() should be compared to 1 instead of 0
(without changing the comment above that function).

An alternative fix for the realtime bug would be 

	weight = 1000 + (p->rt_priority * 2);

in goodness(), so that two realtime tasks with priorities that differ by
1 would have goodness values that differ by more than one.

However, before anyone rushes to implement this, I'd like to suggest
that any performance problems that may be found with the SCHED_OTHER
goodness calculation should be fixed in goodness(), if at all possible,
and not leak out as an undocumented magic number into reschedule_idle().

Nigel Gamble                                    nigel@nrg.org
Mountain View, CA, USA.                         http://www.nrg.org/

MontaVista Software                             nigel@mvista.com

Re: reschedule_idle changes in ac kernels

[Mike Kravetz]

I ran the VolanoMark and TPC-H benchmarks on an 8 CPU system
to observe the differences when changing the value at which
preemptions are triggered.  I used the 2.4.5 kernel as a basis
and only changed the 'max_prio = ' statement in reschedule_idle()
to change the preemption trigger threshold.  In the 2.4.5 kernel
the value of max_prio is set to 1.

The results:

In VolanoMark, changing the preemption trigger from 1 to 0
resulted in a 4% drop in throughput.

In TPC-H there was virtually no difference when going from
1 to 0.  If anything, the results were slightly better with
0 as a threshold value as opposed to 1.

My guess is that the threshold value was changed from 0 to
1 in the 2.4 kernel for better performance with some workload.
Anyone remember what that workload was/is?

-- 
Mike Kravetz                                 mkravetz@sequent.com
IBM Linux Technology Center