the value of PROC_CHANGE_PENALTY

the value of PROC_CHANGE_PENALTY

[Tsafrir Dan]

as I understand, for i386 in Linux-2.2.x the default length
of a quantum was 200ms, and in 2.4.x it had changed to 50ms
(
 according to the following 2.4.5 sched.c code:

    #if HZ < 200
    #define TICK_SCALE(x)   ((x) >> 2)
    ...
    #define NICE_TO_TICKS(nice)     (TICK_SCALE(20-(nice))+1)
    ...
    /* in the `recalculate' portion of schedule(): ... */
    for_each_task(p)
        p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
)

But, 
the value of PROC_CHANGE_PENALTY was not changed accordingly, and is 
still 15. This means that the result of the following goodness() code:
    if (p->processor == this_cpu)
        weight += PROC_CHANGE_PENALTY;
is that any task that executed on `this_cpu' (goodness > 15) 
will always be more "desirable" then a task that executed on 
another cpu (goodness <= 6) which was not the case in 2.2.x .

am I correct ?
and if so, is this what the authors meant, or did they simply forget
to update PROC_CHANGE_PENALTY's value when moving from 2.2 to 2.4 ?

please cc me: dants@cs.huji.ac.il
thanks, dan.

Re: the value of PROC_CHANGE_PENALTY

[Tsafrir Dan]

On Mon, 4 Jun 2001, Mark Hahn wrote:

> > am I correct ?
> > and if so, is this what the authors meant, or did they simply forget
> > to update PROC_CHANGE_PENALTY's value when moving from 2.2 to 2.4 ?
>
> I don't believe anyone has proposed a relation between nice
> and cpu-affinity; the latter has always been a fairly arbitrary 
> constant.

I see, but even so, in linux-2.2 this arbitrary constant allows a non
realtime task to migrate, and totally prohibits it in linux-2.4 (unless
some other cpu is idle).
i.e. maybe there is no relation between the max value of the static 
priority and PROC_CHANGE_PENALTY, but you get a scheduler that behaves
quite differently when you change one without the other.

I think that if it's indeed an arbitrary value, then it should have 
been modified along with the modification of the quantum's length,
because this way the 2.2 behavior (which I assume somebody adopted for
a reason) would have remained the same.

However, if you say that PROC_CHANGE_PENALTY does somehow embody the
cpu-time wasted because of migration (due to cache etc.) regardless of
the quantum's length, then PROC_CHANGE_PENALTY should probably remain 
the same and I got my answer.

Is this what you mean ?

thanks, Dan.