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