public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Mike Galbraith <efault@gmx.de>
Cc: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] O3int interactivity for 2.5.74-mm2
Date: Mon, 7 Jul 2003 20:25:18 +1000	[thread overview]
Message-ID: <200307072025.18711.kernel@kolivas.org> (raw)
In-Reply-To: <5.2.1.1.2.20030707110403.02843af0@pop.gmx.net>

On Mon, 7 Jul 2003 19:40, Mike Galbraith wrote:
> At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
> >Thanks to Felipe who picked this up I was able to find the one bug causing
> > me grief. The idle detection code was allowing the sleep_avg to get to
> > ridiculously high levels. This is corrected in the following replacement
> > O3int patch. Note this fixes the mozilla issue too. Kick arse!!
>
> I took this out for a spin in stock 74.  If I do while true; do sh -c 'ps l
> $$'; date; sleep 1; done, the shell is running at priority 22.  In the face

You're hitting spot on the idle detection code. Sleep for a second or longer 
and this patch makes you get only your static priority. This way if you 
suddenly become a cpu hog you cant starve the machine. ie. it works with your 
test exactly as I planned it.

> of any load, that leads to quite long response times.  With a make -j5
> bzImage running, I frequently saw response times of over a second.  In X,
> with a make -j2 bzImage running, opening a new shell takes too long, and X

Yes I was planning on increasing the child penalty to 95 once the other things 
settled down. This will speed up start time.

> loses interactive status considerably quicker than stock when doing window

The sleep avg decrements at the same place and at the same rate in my patch as 
it does in stock, so I can't see how that's happening.

> wiggle.  Init is at 20, and kernel threads bounce around between 15 and 20
> depending on how active they are (doesn't seem good considering they're
> using practically no cpu).

They're idle. Why do they need higher priority?

> Thud is still dead, but maybe _too_ dead ;-)  I never saw it get above the
> lowest priority, which is very unfair considering the amount of sleeping it
> does.

It sounds like you're applying your idea of what you expect the priority to be 
based on previous algorithms rather than judging it on it's own merits. I 
didn't see any mention of whether audio skips less or mouse moves smoother 
which is what it's addressing. The data shows it doesn't unfairly 
disadvantage other tasks. CPU hogs get treated as such.

Con


  reply	other threads:[~2003-07-07 10:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-06 17:16 [PATCH] O3int interactivity for 2.5.74-mm2 Con Kolivas
2003-07-06 18:36 ` Felipe Alfaro Solana
2003-07-06 21:14   ` Con Kolivas
2003-07-06 21:17   ` Con Kolivas
2003-07-07  3:19   ` Con Kolivas
2003-07-07  9:13     ` Felipe Alfaro Solana
2003-07-07  9:40     ` Mike Galbraith
2003-07-07 10:25       ` Con Kolivas [this message]
2003-07-07 14:06         ` Mike Galbraith
2003-07-07 14:10           ` Con Kolivas
2003-07-07 10:51     ` Nick Sanders
2003-07-07 12:19       ` Marc-Christian Petersen
2003-07-07 13:14         ` Con Kolivas
2003-07-08  0:31         ` Zwane Mwaikambo
2003-07-09 10:12           ` Marc-Christian Petersen
2003-07-09 10:13             ` Marc-Christian Petersen
2003-07-09 10:22             ` Con Kolivas
2003-07-09 10:23               ` Marc-Christian Petersen
2003-07-09 10:37                 ` Con Kolivas
2003-07-09 10:40                   ` Marc-Christian Petersen
2003-07-07 13:25     ` Helge Hafting
2003-07-08  6:35     ` Alex Riesen
2003-07-08  7:11     ` Szonyi Calin
2003-07-08  7:46       ` Davide Libenzi
2003-07-08  7:59         ` Con Kolivas
2003-07-08 15:12           ` Davide Libenzi
2003-07-08 20:54             ` Con Kolivas
2003-07-08 20:55               ` Davide Libenzi
2003-07-08  8:03       ` Con Kolivas
2003-07-10 16:27         ` Szonyi Calin
  -- strict thread matches above, loose matches on Subject: below --
2003-07-09 15:08 Luis Miguel Garcia

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=200307072025.18711.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=felipe_alfaro@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    /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