[lkml]   [2004]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [announce] [patch] Voluntary Kernel Preemption Patch
    While locking a RT process to a CPU to achieve even lower latencies 
    might be useful to some
    the general userbase wants good latencies on simple UP, non HT-enabled
    hardware too.
    (AMD is gaining marketshare and we cannot simply expect that good
    multimedia performance (aka low latency)
    can be achieved only on those SMP/HT boxes where the truth is that
    except in the case of really crappy hardware,
    those common UP machines are actually capable to delives latencies in
    the range of dozen of usecs.
    (taking the RTLinux benchmarks as reference).
    Of course Linux != RTLinux and we never expect nor pretend Linux to
    match the response time of RTLinux but
    as said earlier latencies at around 1msec should are doable on decent UP
    boxes and this is more than
    adequate to run demanding real time audio applications like software
    synthesizers, samples, real time effects etc.
    The only hope is that the hard work from Ingo, Andrew and all the others
    gets soon integrated in the mainstream
    2.6 kernel so all Linux users can take run demanding multimedia
    applications out of the box without going through
    the painful patching,kernel recompiling etc.
    Or is this still not realistic at this point ?
    (see the old issue with kernel 2.4, low latency patches were too
    unclean to make it into the
    ufficial kernel tree).

    Plus what's very important is that every kernel developer and driver
    developer (even thirdparty, especially those
    that do closed source stuff like Nvidia etc) takes into account the
    latency problems that code paths that run for
    too long time (or disable IRQs for too long etc) might create.
    While I'm not a kernel expert I assume the premptible kernel alleviates
    this problem but I guess it still cannot
    completely get rid of low latency-unfriendly routines and drivers.
    Perhaps in upcoming Linux kernel/driver programming books this issue
    should be stressed out and
    mentioned prominently in order to avoid the eternal:
    fixing latencies in kernel x.y.z -> new kernel versions with new
    drivers/changes/enhancements comes out
    -> latencies are bad again -> fix latencies in this new kernel version
    ..... ( iterate at infinitum)


    Lee Revell wrote:

    >On Tue, 2004-07-20 at 14:11, Ralf Beck wrote:
    >>>it's an issue for all block IO drivers that do IO completions from IRQ
    >>>context and that can do DMA - i.e. every block IO hardware that uses
    >>>interrupts. This includes SCSI too. In fact for SCSI it's a norm to have
    >>I renew a question i asked earlier.
    >>To my understanding, on a SMP or hyperthreading system, disabling of
    >>IRQs is always local to one (virtual on HT) cpu.
    >>So would it be possible to get ultralow latency by simply hardlock all irqs
    >>and processes to cpu1 and the irq triggering the audiothread (together with
    >>the audiothread) to cpu 2 using the sched_affinity and irq-affinity
    >>capabilites of the kernel?
    >>This would be an easy to use lowlatency hardware patch for linux audio users
    >>with SMP/HT systems. Anybody knows?
    >>I'm currently thinking about getting a new system and consider a dualsystem if
    >>this worked.
    >Should work. For example, the RTLinux people report excellent results
    >on SMP systems by binding all RT threads to one CPU and having the Linux
    >part of the system run on the other. This is just a "softer" version of
    >that setup. Even if there are cases where IRQs are disabled globally,
    >it would be an improvement. I suspect you are not getting much of a
    >response because no one has actually tested it with an audio system.

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

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