Re: [PATCH]O18.1int

[Nick Piggin]

Thomas Schlichter wrote:

> On Saturday 23 August 2003 07:55, Con Kolivas wrote:
>
> > Some high credit tasks were being missed due to their prolonged cpu burn at
> > startup flagging them as low credit tasks.
> >
> > Low credit tasks can now recover to become high credit.
> >
> > Con
>
> Hi Con!
>
> First of all... Your interactive scheduler work is GREAT! I really like it...!
>
> Now I tried to unterstand what exacly the latest patch does, and as far as I 
> can see the first and the third hunk just delete respectively expand the 
> macro VARYING_CREDIT(p). But the second hunk helps processes to get some 
> interactive_credit until they become a HIGH_CREDIT task. This looks 
> reasonable to me...
>
> So, now I wanted to know how a task may lose its interactive_credit again... 
> The only code I saw doing this is exaclty the third hunk of your patch. But 
> if a process is a HIGH_CREDIT task it can never lose its interactive_credit 
> again. Is that intented?
>
> I think the third hunk should look like following:
> @@ -1548,7 +1545,7 @@ switch_tasks:
>        prev->sleep_avg -= run_time;
>        if ((long)prev->sleep_avg <= 0){
>                prev->sleep_avg = 0;
> -               prev->interactive_credit -= VARYING_CREDIT(prev);
> +               prev->interactive_credit -= !(LOW_CREDIT(prev));
>        }
>        prev->timestamp = now;
>
> As an additional idea I think interactive_credit should be allowed to be a bit 
> bigger than MAX_SLEEP_AVG and a bit lower than -MAX_SLEEP_AVG. This would 
> make LOW_CREDIT processes stay LOW_CREDIT even if they do some sleep and 
> HIGH_CREDIT processes star HIGH_CREDIT even if they do some computing...
>
> But of course I may completely miss something...

Hi
I don't know what is preferred on lkml, but I dislike mixing booleans
and integer arithmetic.

if (!LOW_CREDIT(prev))
   prev->interactive_credit--;

Easier to read IMO.


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