Re: [PATCH] set_cpus_allowed() for 2.4

Andrew Morton (akpm@digeo.com)
Tue, 03 Dec 2002 16:30:28 -0800


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.
-
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/