From: Con Kolivas <kernel@kolivas.org>
To: Thomas Schlichter <schlicht@uni-mannheim.de>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]O18.1int
Date: Sat, 23 Aug 2003 22:21:14 +1000 [thread overview]
Message-ID: <200308232221.15333.kernel@kolivas.org> (raw)
In-Reply-To: <200308231108.48053.schlicht@uni-mannheim.de>
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.
next prev parent reply other threads:[~2003-08-23 12:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-23 5:55 [PATCH]O18.1int Con Kolivas
2003-08-23 9:08 ` [PATCH]O18.1int Thomas Schlichter
2003-08-23 9:18 ` [PATCH]O18.1int Nick Piggin
2003-08-23 12:22 ` [PATCH]O18.1int Con Kolivas
2003-08-23 12:21 ` Con Kolivas [this message]
2003-08-23 9:32 ` [PATCH]O18.1int Andrew Morton
2003-08-23 9:49 ` [PATCH]O18.1int Nick Piggin
2003-08-23 16:58 ` [PATCH]O18.1int Con Kolivas
2003-08-23 21:49 ` [PATCH]O18.1int Andrew Morton
2003-08-24 2:46 ` [PATCH]O18.1int Con Kolivas
2003-08-23 13:29 ` [PATCH]O18.1int Con Kolivas
2003-08-25 9:24 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 9:42 ` [PATCH]O18.1int Alex Riesen
2003-08-25 10:16 ` [PATCH]O18.1int Con Kolivas
2003-08-25 10:21 ` [PATCH]O18.1int Alex Riesen
2003-08-25 21:02 ` [PATCH]O18.1int Alex Riesen
2003-08-25 22:48 ` [PATCH]O18.1int Con Kolivas
2003-08-25 23:00 ` [PATCH]O18.1int Alex Riesen
2003-08-26 22:03 ` [PATCH]O18.1int Alex Riesen
2003-08-25 10:34 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:50 ` [PATCH]O18.1int Con Kolivas
2003-08-25 11:15 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 11:37 ` [PATCH]O18.1int Con Kolivas
2003-08-25 11:58 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 12:28 ` [PATCH]O18.1int Con Kolivas
2003-08-25 12:49 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 13:32 ` [PATCH]O18.1int Con Kolivas
2003-08-25 10:17 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:34 ` [PATCH]O18.1int Alex Riesen
2003-08-25 11:23 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:48 ` [PATCH]O18.1int Con Kolivas
[not found] ` <3F49E482.7030902@cyberone.com.au>
[not found] ` <20030825102933.GA14552@Synopsys.COM>
2003-08-26 22:20 ` [PATCH]O18.1int Alex Riesen
2003-08-27 2:26 ` [PATCH]O18.1int Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2003-08-23 22:03 [PATCH]O18.1int Voluspa
2003-08-24 4:04 ` [PATCH]O18.1int Con Kolivas
2003-08-28 12:23 [PATCH]O18.1int Guillaume Chazarain
2003-08-28 13:43 [PATCH]O18.1int Guillaume Chazarain
2003-08-28 13:58 ` [PATCH]O18.1int Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200308232221.15333.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schlicht@uni-mannheim.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox