lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: real-time threaded IO with low latency (audio)
    On Fri, Jul 23, 1999 at 02:20:53AM -0400, Paul Barton-Davis wrote:
    > it depends on what you mean by "any defined time". if a SCHED_FIFO
    > task is *not* running, and an interrupt occurs, then my sense of the
    > kernel code is that you are *guaranteed* that it will be scheduled to
    > run immediately. if the timer interrupts aren't frequent enough for
    > you, you need some other source of interrupts. for these purposes,
    > those of the soundcard itself work pretty well.


    Try running
    while(1){ write(1,buf,1024*1024*8); }

    while a SCHED_FIFO task is scheduled and see response time.
    Linux is designed to optimize average case response time. And it should be.

    > This is what I mean by latency not being a problem. The difficulty
    > arises as soon the system is no longer quiescent: the kernel starts

    Everything is easy when the system is not doing anything.

    > grabbing locks, and the SCHED_FIFO thread gets shut out for several
    > msecs. This is bad for all of us. One reason why BeOS is a
    > "multimedia" OS is that they recognized that the old idea of what an
    > application "does" is wrong (i.e. many "modern" applications do 98% of
    > their I/O to the video card and/or a soundcard).Lock-taking to protect
    > what would have historically been universal (or at least heavily worn)
    > paths through the kernel is now often just an impediment to timely
    > execution. Yes, the scheduler still needs some global locks, as does
    > the VM/MM system, but very else little else should be guarded in the
    > way it is now. Everyone on l-k knows this - its just a big task to
    > change it.

    Linux is not losing time locking/unlocking, it loses response time by not
    preempting tasks in kernel mode. But preempting tasks in kernel mode would
    be a terrible design choice for a general purpose OS and it a terrible pain in the
    ass to maintain.

    BTW: I have never seen any serious performance numbers on BEOS. Do you have a source?



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