Re: [PATCH] set_cpus_allowed() for 2.4

[Andrew Morton <akpm@digeo.com>]

Andrea Arcangeli wrote:
> 
> ...
> >
> > The difference is unlikely to be noticed by many.  (But it should be
> > _better_ than stock 2.4)
> 
> it can't be better in SMP because due its scalability feature we
> completely lose track of the global smp and we only can keep track of
> the single per-cpu queue. Was it on SMP or UP?

The problem with the "interactivity estimator" was observed on
dual CPU.  It has almost vanished in 2.4.20aa1 and I don't think
it needs any more attention.

(BTW: it is not possible to trigger this problem when the background
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)

> ...
> > With a `make -j1' running:
> >
> > - Normal O(1) behaviour in StarOffice 5.2 is 15-30 second delays between
> >   actions.
> >
> > - With 2.4.20aa1, typing into a text document typically had a 2-3 character
> >   delay.
> >
> > - With the standard 2.4 scheduler the delay is zero characters.
> 
> again, I guess that's SMP and that's quite a pain to fix it to be 100%
> equivalent to 2.4 without hurting scalability.

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.

> ..
> 
> Overall I don't see any showstopper with openoffice (or staroffice) on
> my version of the o1 scheduler.

I'd agree that it's not a showstopper.  It's in the "could be improved
a bit sometime" department.

Post-2.4, well, spinning on sched_yield() is a silly way to implement
a graphical application and I don't believe we need to struggle to
support such a thing.

The Open Group say

     The sched_yield() function shall force the running thread to relinquish
     the processor until it again becomes the head of its thread list. It
     takes no arguments.

That's a bit vague, but it does tend to imply that a yield could
relinquish the CPU for a very long time.