[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.021 / U:153.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site