Messages in this thread | | | Date | Fri, 23 Jul 1999 10:01:16 -0600 | From | yodaiken@chelm ... | Subject | Re: 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/
| |