Re: aio rework

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

David Laight wrote:
> It doesn't help much at all...

The point of my rework is not improving aio but fixing a bug.

> 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.

OK, I'll look into this. But the bug in question might stay after a
rewrite ;-)

> In reality it is probably easier to rewrite the apps!

Probably, in my opinion, aio doesn't solve problems of traditional
approach but creates new problems (such as keeping aiocb structs around
and calling aio_error for each request which can be costly, especially
if aio_error is a syscall).

...
> 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.

Not sure I'm following here. Are you saying that if thread creation is
cheap we can afford one thread per aio request model?

Alex