Re: [PATCH] O3int interactivity for 2.5.74-mm2

[Con Kolivas <kernel@kolivas.org>]

On Tue, 8 Jul 2003 00:06, Mike Galbraith wrote:
> At 08:25 PM 7/7/2003 +1000, Con Kolivas wrote:
> >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.
>
> That one is a definite regression in my book.
>
> > > 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.
>
> (dunno, just an observation)
>
> > > 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?
>
> So they can preempt the waker?  kswapd doesn't need to be sitting around
> twiddling it's thumbs after somebody wakes it up, it needs to start working
> right now.  The same for all of it's buddies.  These guys don't need their
> priorities being bounced around.
>
> > > 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
>
> Perhaps, but I don't think so... see below.
>
> >didn't see any mention of whether audio skips less or mouse moves smoother
> >which is what it's addressing.
>
> You have enough folks testing sound and whatnot.  I'm commenting on general
> effects that poked me in the eye during "take it for a spin around the
> block" session.
>
> >  The data shows it doesn't unfairly
>
> That's contest data right?  Contest doesn't have any bursty loads that I
> know of...
>
> >  disadvantage other tasks. CPU hogs get treated as such.
>
> ...and given the scheduler's reaction to thud, I can only assume (yeah, I
> know;) that a bursty load will suffer in the presence of a sustained
> runner.  If you treat all cpu hungry loads the same, you may as well switch
> to two priorities, interactive and not interactive no?  That's what I meant
> by too dead.

Thanks for all these comments. Will try to consider them in further 
development.

Con