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/