Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267026AbTGGNrj (ORCPT ); Mon, 7 Jul 2003 09:47:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267028AbTGGNrj (ORCPT ); Mon, 7 Jul 2003 09:47:39 -0400 Received: from imap.gmx.net ([213.165.64.20]:45471 "HELO mail.gmx.net") by vger.kernel.org with SMTP id S267026AbTGGNrg (ORCPT ); Mon, 7 Jul 2003 09:47:36 -0400 Message-Id: <5.2.1.1.2.20030707125150.00cfadc0@pop.gmx.net> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 07 Jul 2003 16:06:27 +0200 To: Con Kolivas From: Mike Galbraith Subject: Re: [PATCH] O3int interactivity for 2.5.74-mm2 Cc: Felipe Alfaro Solana , linux kernel mailing list , Andrew Morton In-Reply-To: <200307072025.18711.kernel@kolivas.org> References: <5.2.1.1.2.20030707110403.02843af0@pop.gmx.net> <1057516609.818.4.camel@teapot.felipe-alfaro.com> <5.2.1.1.2.20030707110403.02843af0@pop.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3449 Lines: 82 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. -Mike - 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/