Re: Async I/O on IRIX 6.x?

Alex Rousskov wrote:

> I am no more positive now after looking/fixing the actual implementation :).

> I still think that async-io is a good idea, but only if (a) implemented
> efficiently and (b) seamlessly integrated into the rest of the code.
 
> We have done some steps in the direction of (a). For example, the code I am
> testing now has only two mutexes (compared to one per thread) and much
> cheaper communication between the main thread and other threads.

Could you elaborate on this? I have a hard time beleiving you would get
a more efficient implementation by using less mutexes. Especially if
you keep in mind that the old code did not use the mutexes at all..
(unless AIO_PROPER_MUTEX is defined)

> However, since I am not an async-guru, I will post the code here before
> committing it so other people can test it, find bugs, and see if it performs
> better for them.

I am looking forward to see what you have done.

> As for the integration, it would be nice to remove aioCancel and other
> async-oddities from the code, but we have not looked into that yet.

> To keep you interested :), the current code maintains a priority queue for
> pending requests. Current priorities are, off head:
>
> highest:READ
> OPEN(RDONLY)
> CLOSE
> WRITE
> lowest: OPEN(CREATE)

Sounds reasonable, but I am not convinced it is such a good idea to
have close on a lower priority than open. We do not want to run out of
filedescriptors as this is much much worse than saturating the disk.

And you should probably not be as afraid of write. It is mostly a
cheap operation as the hard parts is offloaded to the OS by the buffer
cache, provided that proper VM tuning is in effect.

So if we split close into two categories, one for reads and one for
writes:

highest:READ
        CLOSE(RDONLY)
        OPEN(RDONLY)
        WRITE
        CLOSE(WRONLY)
lowest: OPEN(WRONLY|CREATE)

/Henrik
Received on Tue Jul 29 2003 - 13:15:53 MDT