Re: [PATCH] set_cpus_allowed() for 2.4

From: Andrew Morton (akpm@digeo.com)
Date: Tue Dec 03 2002 - 20:14:40 EST


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 ;)
-
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/



This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:17 EST