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

On Sun, 13 Sep 1998, Henrik Nordstrom wrote:

> What? NLANR looking into async-io? Have you changed your mind on this
> issue? You was not very positive about threading and async-io when we
> spoke in Manchester.

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

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.
 
> Oops.. I thought that store waited for the open to complete, but I see
> now that it doesn't. The only delay there is perhaps when the number of
> filedescriptors runs low and Squid stops accepting new connections. This
> could cause a large number of problems as it does not only overload the
> disks, it also causes the memory to fill quickly causing many swapouts
> to be aborted when their in-memory object is ejected due to lack of
> cache_mem..

Yes, the Squid behavior in that fast-network/slow-disk case used to be very
odd. :)
 
> Maybe we should spend some time on having these queues limited per disk
> (or cache_dir). Many locations may have disks of different speeds,
> especially after upgrading their cache (newer disks faster and larger
> than the older ones).

I think that eventually per-disk segregation of threads should be implemented
(for many reasons, including the one you mentioned). For now, we just need to
keep the queues long enough to keep all the disks busy, I guess. I think
that would solve the problem you describe at the expense of a bit larger
memory requirements.

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)

The first two are important for client response time (hits). The third keeps
the number of FDs low. The last one should not be processed until we have
more important work to do. Other calls should probably go just before
OPEN(CREATE).. This should be squid.conf semi-configurable, I guess. Cool
options like optimize-for-speed versus optimize-for-hit-ratio come to mind...

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