Note: only useful for large I/O. Small reads & writes are faster with
copying than locking page tables.
> 2) _Real_ asynchronous I/Os.
> Means that the kernel tries to start concurrently the IOs if it is
> possible and notifies user of IO completions asynchronously.
Exactly when is a write operation "complete"?
> Now imagine that these semantics also apply to regular files. There is no
> reason they won't, in theory. Then, optimizations that are possible from
> kernel-land caching strategy are also implementable from user-land, with
> obviously some overhead that can be avoided when implemented in the
> kernel.
You can already do much of that using `mmap'. Reading and writing are
both supported through `mmap', there are no copies, and the kernel
doesn't have to do tricky stuff behind the scenes (which may have
unexpected performance impacts, e.g. having to diddle with COW pages,
lock shared pages etc.)
> Using Direct I/Os from user-land synchronously is indeed very bad for
> streaming since everything will rely on disk write caching and prefetching
> ability. But by combining direct IOs with an asynchonous I/O completion
> mechanism, applications are able to implement kind of read-ahead and/or
> write coalescence algorithms as needed.
Read-ahead is easy enough already. Use a separate thread. If you want
to guarantee the data is ready for the streaming thread, read ahead and
mlock a moving page range. Use mmap to avoid copies too. Unexpected
delays due to scheduling? You get that with raw I/O too.
Write coalescing isn't an issue here, is it? Write-behind is automatic
already.
-- Jamie
-
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/