[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: real-time threaded IO with low latency (audio)
    On Fri, Jul 23, 1999 at 08:52:53AM -0400, Paul Barton-Davis wrote:
    > Sure, but that is not the point. The point is that if you have two
    > processes, the first doing:
    > while(1){ write(diskfile,buf,1024*1024*8); }
    > and the second doing:
    > while(1){ write(soundcard,buf,1024*1024*8); }
    > then there is no reason for either of them to interfere with the other
    > in any way other than needing a certain number of CPU cycles. We could
    > add

    They compete for buffer space and for copying time (kernel cpu cycles).

    > and this would remain true. As long as the write()'s typically cause a
    > task to block, no write() to another i/o subsystem should be held up

    But a smart i/o system, like in Linux, will do all sorts of clever things
    like batching i/o, reordering i/o, using the page cache for i/o buffers ...
    All these things cause writes to interact and in most cases they speed up
    operation of the system.

    > during the block. This is not currently true. I don't know enough
    > about it to know how hard it would be to change, but anything that
    > assumes that a-file-is-a-file-is-a-file below the write() system call
    > interface is extremely unfriendly.

    Process A writes to bytes 10,000-15,000 of file Z
    Process B reads bytes 10,000-15000 from file Z

    the very friendly i/o subsystem recognizes that instead of doing disk i/o, it
    can simply copy data from the write buffers of A into the address space of B!
    And then process C writes to bytes 14,000-18000 of the same file and
    the i/o subsystem figures out the correct thing to do.
    Because the page cache is tied in quite closley to the file systems.

    > >Linux is not losing time locking/unlocking,
    > Sorry Victor, but it *is*. There are well documented pathways through
    > the disk subsystem alone that cause other tasks to have to wait
    > because of lock acquisition/release. Even if we did preemption, it

    Details? I'm interested for a couple of reasons. One of the reasons is that I
    have only seen one case where RT I/O made sense so far, and we are working on
    a ethernet driver that will snarf RT packets before linux sees them and jump the
    queue for Txs. That makes sense in some situations. For disk i/o I don't see
    exactly what is needed.

    > >BTW: I have never seen any serious performance numbers on BEOS. Do you have a
    > >source?
    > Only their own claims, which are too good to be made up :)

    Of course.

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