Re: async-io

Adrian Chadd wrote:

> I meant a queue of operations which is maintained linearly. Then you
> can look at implementing elevator sorts and simple clustering/prefetching
> where applicable. I don't want to have too much magic in the aiops
> code, but enough to prevent replication of code.

It is a single linear FIFO queue where all unstarted operations live
until the async-io request sheduler assigns them to a worker thread one
request per thread at a time.

For the UFS store there isn't much clustering or elevator sorting to
perform as there only are one outstanding request per fd at a time.. For
COSS it might be an idea to elevator sort reads, but I am not sure the
benefit is that high from it. There are a lot simpler optimizations from
which I expect a lot more to be gained.

What is needed from a performance point of view is probably to move from
a Unix API centric approach to a more data centric approach. The current
async-io operation for a single object typically looks like

1a) Schedule open()
1b) Wait for completetion
2a) Schedule read/write of the first 4KB of data
2b) Wait for completetion
3a) Schedule read/write of the next 4KB of data
3b) Wait for completetion.. repeat if neccesary
4a) Schedule close()
4b) Wait for completetion

I.e. for a typical object there are at least 4 calls (8 transitions),
which easily can be optimized to only one call (2 transitions)

1a) Schedule read/write of "/path" using a somewhat larger buffer size
(i.e. 32K or similar)
1b) Wait for completeion

In a way quite similar to how the StoreIO interface operates.

Doing this requires async-io operations to be defined at a higher level
than the traditional file API (open/read/write/close). These ideas for
this were laid out a very long time ago
<http://squid.sourceforge.net/hno/async-io.html>, but I have never got
to the point of actually doing anything of them. Now with the StoreIO
API it shouldn't be that hard I guess.

/Henrik
Received on Sun Apr 23 2000 - 18:05:54 MDT