[lkml]   [1999]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Scheduling latencies news: less RAM = less latency
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
The profiling-patch is on my page if you want.


Benno Senoner
Linux scheduling latency benchmarks

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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