Re: [PATCH] 2.5.72 O(1) interactivity bugfix

[Con Kolivas <kernel@kolivas.org>]

On Thu, 19 Jun 2003 16:35, Con Kolivas wrote:
> On Thu, 19 Jun 2003 16:13, Mike Galbraith wrote:
> > At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
> > >On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> > > > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > > > > I had another look at 2.5 and noticed the max sleep avg is set to
> > > > > 10 seconds instead of 2 seconds in 2.4. This could make a _big_
> > > > > difference to new forked tasks if they all start out penalised as
> > > > > most
> > > > > non-interactive. It can take 5 times longer before they get the
> > > > > balance right. Can you try with this set to 2 or even 1 second on
> > > > > 2.5?
> > > >
> > > > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> > > > skipping here, a song *may* skip during desktop switches sometime
> > > > during the first 5 sec or so of playback IFF make -j20 is running. On
> > > > a mostly idle box (well LoadAvg 3 or so is mostly idle isnt it? ;)
> > > > desktop switching doesnt cause skips anymore 8)
> > >
> > >That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to
> > > half that as well. What you describe makes perfect sense given that
> > > achieving a balance is an exponential function where the MSA is the
> > > time constant.
> >
> > However, that will also send X and friends go off to the expired array
> > _very_ quickly.  This will certainly destroy interactive feel under load
> > because your desktop can/will go away for seconds at a time.  Try to drag
> > a window while a make -j10 is running, and it'll get choppy as heck. 
> > AFAIKT, anything that you do to increase concurrency in a global manner
> > is _going_ to have the side effect of damaging interactive feel to some
> > extent.  The one and only source of desktop responsiveness is the large
> > repository of cpu ticks a task is allowed to save up for a rainy day.
>
> Indeed that's what I thought and found as well. I have a question though -
> do non interactive tasks have periods of inactivity where they collect
> sleep times or is it just interactive tasks that exhibit this? Why I'm
> asking is, what if the interactivity bonus is based on the best interactive
> setting that task has received, and make this one much slower at decaying
> than the sleep_avg. Say one second for max_sleep_avg and 60 seconds for
> max_interactive_bonus? So it can become interactive very quickly (and
> therefore also should start as non interactive) but becomes non-interactive
> slowly.

I tried creating this myself and on first testing it seems the best all round 
so far. I'll make a patch later on for ppl to try, but in a nutshell it does 
this in sched.h:

	unsigned long sleep_avg;
+	unsigned long best_sleep_avg;
	unsigned long sleep_timestamp;

this in sched.c:

#define MAX_SLEEP_AVG          (HZ)

...

	bonus = 
MAX_USER_PRIO*PRIO_BONUS_RATIO*(p->best_sleep_avg/100)/MAX_SLEEP_AVG/100 -
			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;


...
			p->sleep_avg = MAX_SLEEP_AVG;
+		if ((p->sleep_avg * 100) > p->best_sleep_avg)
+			p->best_sleep_avg = p->sleep_avg * 100;
		p->prio = effective_prio(p);

...

		p->sleep_avg--;
+	if (p->best_sleep_avg)
+		p->best_sleep_avg--;

...
	p->rt_priority = lp.sched_priority;
+	p->sleep_avg = 0;
+	p->best_sleep_avg = 0;

and this in fork.c:

	p->sleep_timestamp = jiffies;
+	p->sleep_avg = 0;
+	p->best_sleep_avg = 0;


Sorry I dont have a full patch for people to try at this moment as there are 
so many O(1) kernels I"m working with. This basically works out the sleep 
average over 1 second, but the priority on the best over 100 seconds.

Con