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
