From: Con Kolivas <kernel@kolivas.org>
To: Thomas Schlichter <schlicht@uni-mannheim.de>
Subject: Re: [PATCH]O18.1int
Date: Sat, 23 Aug 2003 22:21:14 +1000
User-Agent: KMail/1.5.3
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>
References: <200308231555.24530.kernel@kolivas.org> <200308231108.48053.schlicht@uni-mannheim.de>
In-Reply-To: <200308231108.48053.schlicht@uni-mannheim.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308232221.15333.kernel@kolivas.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2505
Lines: 57

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/