Re: async-io network / future Squid design

Danilov Nikita wrote:

> Approximately the same thing is described in
> http://www.usenix.org/publications/library/proceedings/
> usenix99/full_papers/banga/banga_html/index.html

Quite interesting paper, but it halts a little in that it compares their
improved model to the select() model and not the poll() or signal models
which they only mention briefly. Their proposed API is quite what I
asked for yes, but it would be interesting to have it in proper relation
to the poll() and signal based models, not only the select() based model
which most people have abandoned since long.

To continue the discussion I have made some additional Linux timing, and
it indicates that sigqueue and sigwaitinfo/sigtimedwait are quite fast
calls, sigqueue+sigwait is about 5 usec together. Assuming sigqueue and
sigwaitinfo is of approximately the same complexity then they take about
2.5 usec each.

A sigtimedwait with a empty queue ends up at about 1.2 usec. However,
without my kernel patch it apparenly cannot handle a zero timeout and
blocks for 10msec. Will send that patch to the linux-kernel list
shortly.

So lets speculate that we have 200 disk I/O objects per second. For each
object we have 5 disk operations. For signal queue based AIO
notification this translates to 200*5*5 usec = 5 msec, or 0.5% CPU time.

Actual signal delivery is a quite heavy and destructive operation yes (I
assume. Haven't actually measured this, and is not interested in it
either), but with queued signals we do not actually need signal delivery
and can instead use the signal queue to batch things. The trick is then
to not make the queue overflow more than absolutely needed, and to
properly detect when it happens and deal with it. But first the actual
overhead of poll() should be measured I think.

Also, given the apparently relatively minimal overhead of sigtimedwait I
would say adding a batch version of that call will only give you a
minimal increase in performance if any at all. Not worth the effort.

/Henrik
Received on Wed Sep 20 2000 - 16:07:50 MDT