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 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
and
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans