Re: [PATCH] Re: Pathological case identified from contest

Jim Houston (jim.houston@attbi.com)
Sun, 20 Oct 2002 22:37:43 -0400


Rik van Riel wrote:
>
> On Sat, 19 Oct 2002, Jim Houston wrote:
> > + if (HZ > 100)
> > + return(((p)->prio - MAX_RT_PRIO)*4 + 1);
> > + else
> > + return(((p)->prio - MAX_RT_PRIO)/2 + 1);
> > }
>
> It'd be fun if this code also worked for values of HZ not
> equal to 100 or 1000. Better put HZ somewhere in this
> calculation and make it HZ-independant.

Yes I will clean this up.

> > + * The rq->prio_ind is used to raise/rotate the priority of all of the
> > + * processes in the run queue. I know this sounds like a pyramid scheme.
> > + * This increase in priority is balanced by two feedback mechanisms.
> > + * First processes which consume there timeslice are moved to a lower
> > + * priority queue. To continue the pyramid analogy we make the time
> > + * slice smaller for more favorable priorities.
>
> Sounds like a good strategy, at least in theory. I suspect
> it'll balance itself well enough to also work in practice.
>
> > + * The rotate_rate is the rate at which the priorities of processes
> > + * in the run queue increase. With the initial HZ/10 guess a process
> > + * will go from the worst dynamic priority to the best in 4 seconds.
>
> How long does it take for a best priority process to go
> down ?

I don't know yet. My next step will be to instrument this.
There are a many things that I can be tuned here, but I
want the system to tune itself. For example, I might measure the
interval at which the lowest priority process gets to run and use
this to adjust the rotate_rate.

>
> Or, for how much time can a newly started CPU hog starve
> an older process ? This is important to know since eg.
> a newly started Mozilla could starve an already running
> movie player.

The patch starts new processes with a neutral priority
of 120. If it is a cpu hog, it will get one time slice at
each priority until it reaches the priority where the existing
group of cpu hogs are executing. At this point it will
round robin with this group.

The scheduler has no way to know which processes are interactive. In
your example the user might be waiting for the Mozilla to start
and not care if the movie player skips.

Jim Houston - Concurrent Computer Corp.
-
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/