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

On Mon, 14 Sep 1998, Henrik Nordstrom wrote:

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

Right, except that with AIO_PROPER_MUTEX undefined threads where using
expensive "timed" condition wait, and one could hardly add anything to the
code without running into race conditions. Also, without mutexes, the thread
scheduling itself was "unpredictable" as some (all?) pthread man pages
suggest. Defining AIO_PROPER_MUTEX was not a good idea as well because then
synchronization became extremely expensive.

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

Agree. We have a FD_limit/response time tradeoff here. Should be
configurable.
 
> 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.

Agree, but user response time may be more important. Fast write does not
improve it.
 
> 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)

Some may want to move OPEN(RDONLY) before READ because it affects user
response time. The position of close(RDONLY) can be before OPEN(RDONLY).

I think we should make the order semi-configurable and let people experiment
with this [probably [very]] important tuning knob.

Alex.
Received on Tue Jul 29 2003 - 13:15:53 MDT