Hidden at the end of a thread titled "[PATCH] 2.5.72 O(1) interactivity
bugfix" was a much improved patch for interactivity against 2.5.72 which
seemed to be swallowed and never appeared on lkml so here it is again.
If a task is interactive it will declare itself in a short period and the
max_sleep_avg being 10 seconds is too long for a task to be detected as such.
Unfortunately decreasing the max_sleep_avg will quickly put a task onto the
expired array if the task uses sustained cpu for a period. This makes X slow
down after a little usage when the machine is under heavy load.
This patch uses two settings to determine a task's interactivity, the old
max_sleep_avg is now more of a sleep_avg "attack" and the new
best_sleep_decay is the decay. Initially these have been set to 1 and 60
seconds. Audio skipping is eliminated in my testing at heavy loads, and X
does not slow down during sustained usage under very heavy load. Unlike my
previous patch this one does not reset the sleep_avg of new forked processes.
Included as an attachment to prevent mailer mangling.
Testers required. A version for -ck will be created soon.
Con
At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
>Testers required. A version for -ck will be created soon.
That idea definitely needs some refinement.
Run test-starve.c, and try to login. I'm not sure, but I don't think I've
seen any task change more than one priority from what it started life
at. In test-starve's case, that's 16. It's partner is at 16 as well, so
it can't preempt (bad). A dd if=/dev/zero of=/dev/null stays glued to
21. Repeated sh -c 'ps l $$' bounces back and forth between 15 and
21. (maybe I should fly to Vegas.. when I try to login with test-starve
running, I keep hitting 21:)
-Mike
On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> >Testers required. A version for -ck will be created soon.
>
> That idea definitely needs some refinement.
>
> Run test-starve.c, and try to login. I'm not sure, but I don't think I've
> seen any task change more than one priority from what it started life
> at. In test-starve's case, that's 16. It's partner is at 16 as well, so
> it can't preempt (bad). A dd if=/dev/zero of=/dev/null stays glued to
> 21. Repeated sh -c 'ps l $$' bounces back and forth between 15 and
> 21. (maybe I should fly to Vegas.. when I try to login with test-starve
> running, I keep hitting 21:)
Heh, sounds like you'll get to go there lose all your money come back and
still be waiting :P
Too fast a woody that stays up too long?
Perhaps 2 seconds up and 10 down would be better than 1 up 60 down. I was just
trying to make a point with those numbers; they were hardly tuned. Also
perhaps the child penalty of 50 is now too low and IIRC the 95 used a long
time ago may give the shell a better chance of firing up.
Con
On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> >Testers required. A version for -ck will be created soon.
>
> That idea definitely needs some refinement.
Actually no it needs a bugfix even more than a refinement!
The best_sleep_decay should be 60, NOT 60*Hz
Con
On Fri, 20 Jun 2003 02:02, Con Kolivas wrote:
> On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > >Testers required. A version for -ck will be created soon.
> >
> > That idea definitely needs some refinement.
>
> Actually no it needs a bugfix even more than a refinement!
>
> The best_sleep_decay should be 60, NOT 60*Hz
Here's a fixed patch.
Con
On Thu, 2003-06-19 at 12:06, Con Kolivas wrote:
> On Fri, 20 Jun 2003 02:02, Con Kolivas wrote:
> > On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > > >Testers required. A version for -ck will be created soon.
> > >
> > > That idea definitely needs some refinement.
> >
> > Actually no it needs a bugfix even more than a refinement!
> >
> > The best_sleep_decay should be 60, NOT 60*Hz
>
> Here's a fixed patch.
Ok, that doesnt really seem to change behavior much (from just a little
testing). I can still easily starve xmms by moving a window around over
mozilla or evolution (I suspect for thoose that use nautilus to draw the
desktop that would happen on an 'empty' desktop too..).
With 2.5.72-mm1, HZ 1000 and MAX_SLEEP_AVG 2 that does *not* happen,
even with a cpu hog running (mpeg2enc) or during make -j20. However with
this kernel, after having moved a window around madly for a while the
mouse pointer is very laggy/jerky for atleast 30 sec after i release the
window (not so with your patch).
I'm not hitting swap at all, so thats not a factor here.
Andreas
On Fri, 20 Jun 2003 02:42, Andreas Boman wrote:
> On Thu, 2003-06-19 at 12:06, Con Kolivas wrote:
> > On Fri, 20 Jun 2003 02:02, Con Kolivas wrote:
> > > On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > > > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > > > >Testers required. A version for -ck will be created soon.
> > > >
> > > > That idea definitely needs some refinement.
> > >
> > > Actually no it needs a bugfix even more than a refinement!
> > >
> > > The best_sleep_decay should be 60, NOT 60*Hz
> >
> > Here's a fixed patch.
>
> Ok, that doesnt really seem to change behavior much (from just a little
> testing). I can still easily starve xmms by moving a window around over
> mozilla or evolution (I suspect for thoose that use nautilus to draw the
> desktop that would happen on an 'empty' desktop too..).
>
> With 2.5.72-mm1, HZ 1000 and MAX_SLEEP_AVG 2 that does *not* happen,
> even with a cpu hog running (mpeg2enc) or during make -j20. However with
> this kernel, after having moved a window around madly for a while the
> mouse pointer is very laggy/jerky for atleast 30 sec after i release the
> window (not so with your patch).
>
> I'm not hitting swap at all, so thats not a factor here.
Ok well next thing to try is max_sleep_avg 2*HZ with my patch, possibly with
best_sleep_decay 10
Con
At 02:02 AM 6/20/2003 +1000, Con Kolivas wrote:
>On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > >Testers required. A version for -ck will be created soon.
> >
> > That idea definitely needs some refinement.
>
>Actually no it needs a bugfix even more than a refinement!
>
>The best_sleep_decay should be 60, NOT 60*Hz
Ok. Now it acts as you described.
thud is also now THUD though, and a parallel kernel build goes insane
pretty much instantly. On the bright side, process_load seems to have lost
it's ability to crawl up (under X) and starve new processes forever.
-Mike
On Thu, 2003-06-19 at 13:31, Mike Galbraith wrote:
> At 02:02 AM 6/20/2003 +1000, Con Kolivas wrote:
> >On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > > >Testers required. A version for -ck will be created soon.
> > >
> > > That idea definitely needs some refinement.
> >
> >Actually no it needs a bugfix even more than a refinement!
> >
> >The best_sleep_decay should be 60, NOT 60*Hz
>
> Ok. Now it acts as you described.
>
> thud is also now THUD though, and a parallel kernel build goes insane
> pretty much instantly. On the bright side, process_load seems to have lost
> it's ability to crawl up (under X) and starve new processes forever.
>
Hmm, I'm still able to completely starve xmms by just moving a window
around ontop of evolution or mozilla though (not possible without this
patch).
Andreas