linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Thomas Schlichter <schlicht@uni-mannheim.de>
Cc: Con Kolivas <kernel@kolivas.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]O18.1int
Date: Sat, 23 Aug 2003 19:18:53 +1000	[thread overview]
Message-ID: <3F47317D.3030802@cyberone.com.au> (raw)
In-Reply-To: <200308231108.48053.schlicht@uni-mannheim.de>



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.



  reply	other threads:[~2003-08-23  9:19 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   ` Nick Piggin [this message]
2003-08-23 12:22     ` [PATCH]O18.1int Con Kolivas
2003-08-23 12:21   ` [PATCH]O18.1int Con Kolivas
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
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=3F47317D.3030802@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=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;
as well as URLs for NNTP newsgroup(s).