Messages in this thread | | | Date | Sun, 13 Jan 2002 21:09:45 -0800 | From | Andrew Morton <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
Daniel Phillips wrote: > > On January 13, 2002 04:36 pm, Arjan van de Ven wrote: > > On Sun, Jan 13, 2002 at 04:18:29PM +0100, Roman Zippel wrote: > > > > > What somehow got lost in this discussion, that both patches don't > > > necessarily conflict with each other, they both attack the same problem > > > with different approaches, which complement each other. I prefer to get > > > the best of both patches. > > > > If you do this (and I've seen the results of doing both at once vs only > > either of then vs pure) then there's NO benifit for the preemption left. > > Sorry, that's incorrect. I stated why earlier in this thread and akpm signed > off on it. With preempt you get ASAP (i.e., as soon as the outermost > spinlock is done) process scheduling. With hand-coded scheduling points you > get 'as soon as it happens to hit a scheduling point'.
With preempt it's "as soon as you hit a lock-break point". They're equivalent, for the inside-lock case, which is where most of the problems and complexity lie.
> That is not the only benefit, just the most obvious one.
I'd say the most obvious benefit of preempt is that it catches some of the cases which the explicit schedules do not - the stuff which the developer didn't test for, and which is outside locks.
How useful this is, is moot.
But we can *make* it useful. I believe that internal preemption is the foundation to improve 2.5 kernel latency. But first we need consensus that we *want* linux to be a low-latency kernel.
Do we have that?
If we do, then as I've said before, holding a lock for more than N milliseconds becomes a bug to be fixed. We can put tools in the hands of testers to locate those bugs. Easy.
- - 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/
| |