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/