Messages in this thread | | | Subject | Re: real-time threaded IO with low latency (audio) | Date | Fri, 23 Jul 1999 15:06:27 -0400 | From | Paul Barton-Davis <> |
| |
>> 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).
they *might* compete for buffer space depending on available memory, and they might not. further, if these guys are burning much *other* than kernel cpu cycles, i'd like to know why :)
>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.
ah victor, you're just not spending enough time with us audio freaks :)
the soundcard ADAC might look like a file, and it might be represented by a node in a filesystem, but it isn't a file. a device like an ADAC, or a serial port, or a parallel port, or a network interface, isn't capable of being bypassed by the page cache - its essentially a bit bucket. the i/o subsystem's efforts on behalf of such devices can be precisely nil - bytes sent to them are never available for retrieval unless the hardware itself does something funky.
and in the tight while() loops, the i/o subsystem doesn't even much a role to play on the input-from-file side, since the data is all coming out of memory which presumably is going to be resident after the first iteration of both loops.
the unix everything-is-a-file model is great from an API point of view, but it doesn't translate very well in kernel internals when many "files" are not data storage devices in any sense.
>> 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.
no, we/i don't need it for disk i/o. we need it for output to an ADAC. i don't know where the locks are that i referred to above, but i know that mingo and andrea and maybe even dave miller have confirmed their existence when Benno first started discussing his latency test.
--p
- 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/
| |