Re: [linux-audio-dev] Re: desktop and multimedia as an afterthought?

From: hui (bhuey_at_lnxw.com)
Date: 07/14/04

  • Next message: jmerkey_at_comcast.net: "[UPDATE REPORT] Ext3 File System "Too many files" with snort" 
    Date:	Tue, 13 Jul 2004 15:08:38 -0700
To: Martijn Sipkema <msipkema@sipkema-digital.com>

    On Tue, Jul 13, 2004 at 11:44:59PM +0100, Martijn Sipkema wrote:
    [...]
    > The worst case latency is the one that counts and that is the contended case. If
    > you could guarantee no contention then the worst case latency would be the
    > very fast uncontended case, but I doubt there are many (any?) examples of this in
    > practice. There are valid uses of mutexes with priority inheritance/ceiling protocol;
    > the poeple making the POSIX standard aren't stupid...

    There are cases where you have to use priority inheritance, but the schemes that are
    typically used either have a kind of exhaustive analysis backing it or uses a simple
    late detection scheme. In a general purpose OS, the latter is useful for various kind
    of overload cases. But if your system is constantly using that specific case, then it's
    a sign the contention in the kernel must *also* be a problem under SMP conditions. The
    constant use of priority inheritance overloads the scheduler, puts pressure on the
    cache and other negative things that hurt CPU local performance of the system.

    The reason why I mention this is because of Linux's hand-crafted nature of dealing
    with this. These are basically contention problems expressed in a different manner.
    The traditional Linux method is the correct method of deal with this in a general
    purpose OS. This also applies to application structure as well. The use of these
    mechanisms need to be thought out before application.

    > > > It is often heard in the Linux audio community that mutexes are not realtime
    > > > safe and a lock-free ringbuffer should be used instead. Using such a lock-free
    > > > ringbuffer requires non-standard atomic integer operations and does not
    > > > guarantee memory synchronization (and should probably not perform
    > > > significantly better than a decent mutex implementation) and is thus not
    > > > portable.
    > >
    > > It's to decouple the system from various time related problems with jitter.
    > > It's critical to use this since the nature of Linus is so temporally coarse
    > > that these techniques must be used to "smooth" over latency problems in the
    > > Linux kernel.

    > Either use mutexes or POSIX message queues... the latter also are not
    > intended for realtime use under Linux (though they are meant for it in
    > POSIX), since they don't allocate memory on creation.
     
    The nature these kind of applications push into a very demanding space where
    typical methodologies surrounding the use of threads goes out the window. Pushing
    both the IO and CPU resources of a kernel is the common case and often you have to
    roll your own APIs, synchronization mechanisms to deal with these problem. Simple
    Posix API and traditional mutexes are a bit too narrow in scope to solve these
    cross system concurrency problems. It's not trivial stuff at all and can span
    from loosely to tightly coupled systems, yes, all for pro-audio/video.

    Posix and friends in these cases simply aren't good enough to cut it.

    > > I personally would love to see these audio applications run on a first-class
    > > basis under Linux. Unfortunately, that won't happen until it gets near real
    > > time support prevasively through the kernel just like in SGI's IRIX. Multimedia
    > > applications really need to be under a hard real time system with special
    > > scheduler support so that CPU resources, IO channels can be throttled.
    > >
    > > The techniques Linux media folks are using now are basically a coarse hack
    > > to get things basically working. This won't change unless some fundamental
    > > concurrency issues (moving to a preemptive kernel with interrupt threads, etc..)
    > > change in Linux. Scattering preemption points manually over 2.6 is starting to
    > > look unmanable from all of the stack traces I've been reading in these latency
    > > related threads.
    >
    > Improving the mutex and mqueue implementations to better support realtime
    > use would be a significant improvement I think, making Linux quite suitable
    > for realtime audio use.

    Yes and no. This really all really needs to be hard real time in the long run.
    With things like Tivo and other embedded application putting high demand on kernel
    resources this kind of stuff needs to go into the Linux kernel sooner rather than
    later so that Linux can keep up with current industry tracks.

    That's my two cents. :)

    bill

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: jmerkey_at_comcast.net: "[UPDATE REPORT] Ext3 File System "Too many files" with snort"

    Relevant Pages

    • Re: OS Overhead
      ... I know this is gross estimation, but does the kernel use up 20% of my CPU resources? ... Since you have not said what kind of latency you are expecting in your application, it is hard to figure out what the demands of your product will be. ... I have also worked on systems using Linux on an ARM where we were experiencing latencies on the order of 100 to 150 milliseconds. ... I'm not sure that either of these offers an operating system for 8-bit, but they have customer support and sales support links on their sites and you may be able to get some answers to your questions by contacting them. ...
      (RedHat)
    • Thinking about Linux 4.0...
      ... With the embracing of this new development model, we will speed up Linux ... philosophy of the kernel in a very fundamental way will be shunned. ... going on about reducing latency. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: fastest approach?
      ... you were speaking of run time (latency). ... Please pay attention that Linux is by no means a realtime system. ... course in the Kernel you will have less _average_ latency than ... If you really need to be "fast" I suggest taking a look at RTAI. ...
      (comp.os.linux.embedded)
    • Re: differences between kernel-tree and kernel-source and kernel image
      ... > will this install the kernel or try to patch an existing 2.6 kernel or ... affix-source - Driver source for the Affix Bluetooth protocol stack for Linux ... atlas-doc - Automatically Tuned Linear Algebra Software,documentation ...
      (Debian-User)
    • LTTng finds abnormally long APIC interrupt handler : 58.2 ms
      ... A trace taken with LTTng on a x86_64 dual quad-core, Linux kernel ... # Input Device Drivers ...
      (Linux-Kernel)