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

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.024 / U:0.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site