lkml.org 
[lkml]   [1999]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.104 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site