Re: [PATCH] set_cpus_allowed() for 2.4

[Andrew Morton <akpm@digeo.com>]

Andrea Arcangeli wrote:
> 
> On Tue, Dec 03, 2002 at 04:30:28PM -0800, Andrew Morton wrote:
> > load is just one or more busywaits.  It has to be a compilation.  It
> > could be something to do with all the short-lived processes, or gcc -pipe)
> 
> could be that we think they're very interactive or something like that.

I just retested.  This is on uniprocessor.  Running `make -j1 bzImage',
while typing into a StarOffice 5.2 document:

- 2.4.19-pre4: smooth
- 2.4.20aa1: Jerky.  Sometimes it's OK, sometimes a few characters
  lag.

Then I disabled `-pipe' in the build and restarted it:

- 2.4.19-pre4: smooth
- 2.4.20aa1: Quite a lot more jerky.  Enough to be a bit irritating.

> ...
> >
> > This problem is the "changed sched_yield semantics".  It was actually
> > tested on uniprocessor.  The difference between 2.4 and 2.4-aa is
> > still noticeable here, but it is not a terrible problem now.
> 
> strange, the algorithm should be nearly the same now (modulo RT). Still
> I wonder that's something else on the short lived gcc processes side.

Could be.  Removing -pipe affected it quite a bit.
 
> ...
> the right implementation would be probably to let all the other task
> run, so it can't waste entire timeslices if two tasks runs sched_yield
> in a loop and the holder waits behind them, but that proven to be quite
> slow in pratice for apps like openoffice (really when we tested that
> algorithm there were still various bugs but I still think letting all
> tasks to run before staroffice could make progress was the major reason
> of the slowdown, think all gcc spending their timeslice before you can
> take a mutex etc...).

Yup.  yield() is a very vague thing.  So vague as to make it a bit
useless really.  Anything which depends on it will show large
changes in behaviour as system load changes.  And indeed as the
yield() implementation changes ;)