Re: Scheduling latencies news: less RAM = less latency

Benno Senoner (sbenno@gardena.net)
Sun, 1 Aug 1999 00:23:43 +0200

On Sat, 31 Jul 1999, Linus Torvalds wrote:
> On Sat, 31 Jul 1999, Ingo Molnar wrote:
> >
> > no, it really happens. With 512M RAM and a 4-way Xeon i easily got
> > 20ms+ latencies. These latencies are rare because it's caused by
> > prune_dcache(), but they do happen.
>
> prune_dcache() I can believe. But the report was about d_lookup(). So
> somebody is using bad profiling information, and that's dangerous.
>
> Also, the si_meminfo() etc stuff is just ridiculous. It's not a question
> of latency: it's a question of CPU usage. We need to just get rid of those
> functions instead of hacking around them - regardless of whether you add
> "reschedule" calls in them, they just eat too much CPU, plain and simple.
> Again, please don't treat the symptoms - I will not accept patches that
> just say "oh, this is crap, so let's reschedule a bit here". They need to
> be fixed properly or not at all.
>
> Linus

Linus, I agree that this solution is perhaps not the cleanest,
one thing to check, is how much slower this kernel would be
compared to a standard kernel.
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.
I'm easily willing to trade 1-5% of the CPU in exchange of a responsive <5ms
latency system.
If the performance drop worries you, we could add this as a compile time
option, "kernel optimized for server", or "kernel optimized for multimedia" .

If's ridiculous to get up to 150ms latencies on a powerful machine like the
PII400 on Linux.
Even a Windows user (with a properly tuned machine) laughs at these values.

Simple reschedules in uaccess.h + buffer.c lowered the latency *DRAMATICALLY*
on my box, about an order of magnitude. ( /proc down to 3ms , disk read down
to 6ms)

Linus, what are your proposal for making the kernel "low-latency" in a CLEAN
way ?

I think making the kernel fully preemptable is not an easy task and will
not happen very soon.

Plus what disturbs me is the busy-waiting for RT processes for sleeps <2ms
2ms is PLENTY of time on modern CPUs,and I call THIS wasitng CPU time,
therefore we should change this approach.

comments ?

P.S: the profiling patch and infos are from Roger Larrson
(nra02596@norran.net).
The profiling-patch is on my page if you want.

Benno.

--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio




-
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/