Messages in this thread | | | Date | Sat, 31 Jul 1999 17:44:30 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Scheduling latencies news: less RAM = less latency |
| |
On Sun, 1 Aug 1999, Benno Senoner wrote: > > I think "reschedules" during lenghty kernel operations is not a so bad > idea, the important thing is not to reschedule too often, to avoid wasting > too much CPU time in the scheduler.
Oh, I agree that "reschedule()" can be a very nice thing, and I'm not against adding them where necessary.
The thing that makes me reall ynervous about adding them is that it's a classic case of "easy solution", and once we start going down that path code quality will start suffering if people aren't REALLY careful.
I suspect that in just about _all_ of the really bad cases you can fundamentally trace the badness to Linux being stupid rather than any inherently "lengthy" operation. And then the right fix is to fix the stupidity rather than add a reschedule.
There are cases where this isn't true. A classic such case is a large "read()" system call - where we really may end up doing a really lengthy operation simply because the user asks us to. That's a case where it's not about being stupid, and where a explicit re-schedule makes 100% sense.
But
> I'm easily willing to trade 1-5% of the CPU in exchange of a responsive <5ms > latency system.
It shouldn't be necessary. In most cases bad latency should be traceable to bad performance - you can improve latency by _improving_ performance rather than making it worse.
> If the performance drop worries you, we could add this as a compile time > option, "kernel optimized for server", or "kernel optimized for multimedia" .
That is the Windows NT approach, and it is _wrong_.
> If's ridiculous to get up to 150ms latencies on a powerful machine like the > PII400 on Linux.
Agreed. And it is even more ridiculous to add stupid code to "fix" it.
> Linus, what are your proposal for making the kernel "low-latency" in a CLEAN > way ?
I sent out two of them. "si_meminfo()" should just go away. Same goes for "prune_dcache()", although the latter probably doesn't need to go away, it just needs to have fewer bad corner cases.
> I think making the kernel fully preemptable is not an easy task and will > not happen very soon.
It will not happen EVER.
Pre-emptable kernels are stupid, and anybody who thinks otherwise needs to get his head examined.
But trying to work around bad programming by adding MORE bad programming is also extremely stupid.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |