Regarding benefits of having kernel async I/O support for filesytems,
I would think it should certainly be better from performance point.
Also having all of async I/O in the kernel would mean we don't have
to have the libaio implementation in the user land which is
unnecessarily complicated.
Since there is no kernel async I/O support for UFS, I don't think
we could compare async I/O performance on UFS between
userland version and kernel. Unless some one has hacked the code
and tried it.
-Prakash.
Prakash Sangappa wrote:
That is because the filesystem framework (VFS/VNODE)
and the filesystems do not implement an async I/O interface.
This requires that the relevant modules (filesystems) implement
the necessary I/O queuing and notification mechanism for
async I/O requests.
The kernel async I/O is currently implemented by raw device
interfaces(struct cb_ops - cb_aread/cb_awrite). The I/O completion
notification is done by the kernel async I/O module itself. The
I/O request queue will be managed by the driver.
The kernel async I/O's aio_done routine gets called upon I/O
completion. The 'aio_done' routine is passed as the b_iodone routine
in the buf structure (buf_t).
Having said that, the async I/O requests for files are supported
by means of threads in the libaio library. This is transparent to
the user application as long a they use published aio interfaces.
There was an effort earlier to implement kernel async I/O for
filesystems as well. Basically eliminate the user land threads
mechanism that libaio provides and implement it in the kernel.
That is something to look at. We could add the necessary async
I/O interfaces to the filesystem framework(VFS/VNODE).
Make kernel async I/O support it. That is we could make the
kernel async I/O a generic async I/O framework that
various modules can interact with. It could also provide async I/O
facility for module which do not support async I/O by means of threads
in the kernel(like what is currently
implemented by the libaio library).
-Prakash.
Matty wrote:
Howdy,
Does anyone know why kernel asynchronous I/O is limited to raw
devices? Is
it possible to extend kaio to the file system layer? Would there be any
benefit? Is there a noticeable performance difference between the
userland
and kernel asynchronous I/O implementation when UFS is used with large
Oracle OLTP workloads? Curious to see what folks have seen/measured.
Thanks for any insight,
- Ryan
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
