lkml.org 
[lkml]   [2003]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH]O18.1int
Date
On Sat, 23 Aug 2003 19:08, 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.

> First of all... Your interactive scheduler work is GREAT! I really like
> it...!

Thank you. I never assume no news is good news so I appreciate that.

> 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?

Yes indeed it is.

> I think the third hunk should look like following:
[snip]

> 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...

Originally flagged HIGH_CREDIT and LOW_CREDIT tasks had no limit on how much
credit they could accumulate or lose. This worked in practice but I needed
some cutoff beyond which they would be one or the other and MSA seemed a
decent number. At some stage if it was boundless there would be variable
overflow as well and checking for this was unecessary overhead. I dont want
tasks flagged as high credit to be forgotten though so thats why I dont let
them change. Originally the same idea was for low credit tasks but that
proved to occasionally choose X during startup as low credit. Higher numbers?
perhaps but really this depends on hardware as to what is perfect.

Cheers,
Con

P.S. All this may be moot as it looks like I, or someone else, may have to
start again.

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

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.107 / U:2.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site