Messages in this thread | | | From | Benno Senoner <> | Subject | Re: Scheduling latencies news: less RAM = less latency | Date | 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/
| |