Rich man's version of AIO on Linux 2.6.x?

Rich man's version of AIO on Linux 2.6.x?

[Leon Woestenberg]

Hello,

On the state-of-art of asynchronous I/O in Linux. I understand we have
full support for AIO in the Linux 2.6.x kernel but I cannot find how
to use it from user space.


I would like to exploit AIO in hardware and the device driver for it,
by keeping the hardware performing I/O at all times (no setup latency
between requests by allowing multiple
I/O requests to be queued in hardware). Note this is a character
device, not a filesystem.

I implemented aio_read() and aio_write() on my character device
interface, but it's never been called; read() and write() is called
instead.

>From "Understanding the Linux kernel, 3rd edition" I read that glibc
indeed implements aio_read() and friends itself, not through the
kernel AIO syscalls.

<Quote>
Essentially, the aio_read( ) or aio_write( ) library function clones
the current process and lets the child invoke the synchronous read( )
or write( ) system calls; However, this "poor man's" version of the
POSIX functions is significantly slower than a version that uses a
kernel-level implementation of asynchronous I/O.
<End Quote>

I am looking for a rich man's way to use the kernel functionality;
essentially I want my drivers aio_read and aio_write ops to be called.

Regards,
-- 
Leon

Re: Rich man's version of AIO on Linux 2.6.x?

[Michal Hocko]

On Fri 22-05-09 02:59:53, Leon Woestenberg wrote:
> Hello,

Hi

> 
> On the state-of-art of asynchronous I/O in Linux. I understand we have
> full support for AIO in the Linux 2.6.x kernel but I cannot find how
> to use it from user space.
> 
> 
> I would like to exploit AIO in hardware and the device driver for it,
> by keeping the hardware performing I/O at all times (no setup latency
> between requests by allowing multiple
> I/O requests to be queued in hardware). Note this is a character
> device, not a filesystem.
> 
> I implemented aio_read() and aio_write() on my character device
> interface, but it's never been called; read() and write() is called
> instead.
> 
> From "Understanding the Linux kernel, 3rd edition" I read that glibc
> indeed implements aio_read() and friends itself, not through the
> kernel AIO syscalls.
> 
> <Quote>
> Essentially, the aio_read( ) or aio_write( ) library function clones
> the current process and lets the child invoke the synchronous read( )
> or write( ) system calls; However, this "poor man's" version of the
> POSIX functions is significantly slower than a version that uses a
> kernel-level implementation of asynchronous I/O.
> <End Quote>
> 
> I am looking for a rich man's way to use the kernel functionality;
> essentially I want my drivers aio_read and aio_write ops to be called.

Check the libaio library (io_submit and friends)

> 
> Regards,
> -- 
> Leon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: Rich man's version of AIO on Linux 2.6.x?

[Leon Woestenberg]

Hello,

On Fri, May 22, 2009 at 4:54 PM, Michal Hocko <mhocko@suse.cz> wrote:
> On Fri 22-05-09 02:59:53, Leon Woestenberg wrote:
>> On the state-of-art of asynchronous I/O in Linux. I understand we have
>> full support for AIO in the Linux 2.6.x kernel but I cannot find how
>> to use it from user space.
>>
>> I would like to exploit AIO in hardware and the device driver for it,
>> by keeping the hardware performing I/O at all times (no setup latency
>> between requests by allowing multiple
>> I/O requests to be queued in hardware). Note this is a character
>> device, not a filesystem.
>
> Check the libaio library (io_submit and friends)
>

Thanks, I checked the libaio library. It does not support the POSIX
interface, which I'ld like to use to keep things portable.

The http://www.bullopensource.org/posix/ library is more promising in
that regard but it doesn't seem maintained.

Regards,
-- 
Leon