Re: 2.6.0-test1-mm1

From: Con Kolivas (
Date: Wed Jul 16 2003 - 04:15:29 EST

On Wed, 16 Jul 2003 18:07, Sean Neakums wrote:
> Andrew Morton <> writes:
> > . Another interactivity patch from Con. Feedback is needed on this
> > please - we cannot make much progress on this fairly subjective work
> > without lots of people telling us how it is working for them.
> This patch seems to mostly cure an oddity I've been seeing since
> 2.5.7x, or maybe very late 2.5.6x (I forget exactly when) where
> running 'ps aux' or 'ls -l' in an xterm (and only xterm it seems; I've
> tried rxvt and aterm) would more often than not result in a wallclock
> run time of up to two seconds, instead of the usual tenth of a second
> or so, with system and user time remaining constant. If I keep
> running 'ps aux' its output does start to become slow again, snapping
> back to full speed after a few more runs. Kind of an odd one.

In fact I've seen a number of apps display this problem. Basically how I
understood it was the child was spawned with a lower dynamic priority (50% of
the bonus of the parent with the child penalty at 50%). The parent then was
spinning madly waiting for the child but in the process it was continually
preempting the child. Eventually the parent was seen as a cpu hog, it's
dynamic priority dropped and the child finally got to run along side it. The
next time you ran the same parent/child combination the problem had gone
because the parent was at a lower dynamic priority. Changing child penalty
back up to 95% cures this problem (but can bring other problems with it
unless workarounds are added). While this seems more an anomaly in the coding
of the application brought out by the scheduler, it seems to be very common.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:23 EST