Messages in this thread | | | Date | Tue, 03 Dec 2002 16:30:28 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] set_cpus_allowed() for 2.4 |
| |
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/
| |