Re: aio rework

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Oct 16, 2011 at 10:11:52PM +0100, Alexander Nasonov wrote:
> Hi,
> 
> I recently noticed a flaw with the current implementation of aio, see
> kern/45441. Basically, if you do aio_read and aio_write to one pipe
> you might block a process's aio thread and thus block all aio activity
> with current and future fildes of the process. All you can do in this
> situation is to kill a process.
> 
> One possible solution is using separate threads for reading and writing.
> It's a bit of work but it looks quite straitforward and I can do it at
> my spare time.
> 
> Even with two threads, aio implementation is not optimal but I don't
> have enough knowledge about NetBSD internals to make a better
> implemention.
> 
> What do you guys think of my plan?

It doesn't help much at all...
Without changing all the kernel IO to be request based (rather then
blocking) there isn't really any way to implement async io without
allocating a separate thread for each, and every, aio operation.

The only slight hope - that will help many uses, it is somehow
implement it using non-blocking io and poll/select/kevent for
the devices on which these are available.
This might be most of the devices on which apps try to do async io.

In reality it is probably easier to rewrite the apps!

I've NFI if Linux or Solaris can sensible do aio. RSM11/M could (all
io was async), and windows can for some of drivers (including the
network stack), but windows also supports unix style drivers and
I'm not sure what happens if you try aio on them - it probably
creates a thread specially for the io.

It might be worth looking at how much it actually costs to create
an extra thread on a user process that is never going to return
to userspace. Since it only needs a ref count on the pmap, it might
be relatively cheap.

        David

-- 
David Laight: david%l8s.co.uk@localhost