>On Fri, 6 Jul 2001, Jarom=EDr Dolecek wrote:
>> > a real aio implementation would expose maximum parallelism to the
>> > underlying hardware i/o system.
>
>Absolutely. I saw a linix impl which fronted each aio request with a user
>space thread then muxed everything down to poll/select yeuch. One of my
>apps frequently holds about 60000 socket connections open with each
>connection lasting about 3 minutes with maybe 150Kb of data passed.

interesting use of aio to avoid the poll() loop.

>> How do other OS manage this, e.g. Solaris? (It seems Linux doesn't support
>> this, at least I can't find any mention of aio in 2.3.49 kernel sources).
>
>I'm not sure about Solaris but in HP-UX there seems to be a kernel tunable
>for the max aio requests allowed system wide. I've typically been setting
>this to about 131072 and do not seem to be experiencing any particular
>slowdown.

my WAG says they use that to figure out their hash stuff.  or perhaps
they pre-allocate something.

>A BSD implementation should also be able to handle this number of
>simultaneous aio requests which may be a problem if you have a pool of
>kthreads.

"a pool of kthreads" would imply a many to one mapping of requests to
kthread.  the kthread would be used to actually do the IO; something
would re-act to a stimulus and schedule the kthread to do some work.

in your case, hooks would be added to the socket callbacks (data ready,
write space, etc) and when something appropriate to the aio request
happened, work would be scheduled on the kthread.  you could probably
get away with many, many, many fewer kthreads than outstanding requests.

60,000 conns * 150KB/conn * (3 min * 60 secs/min) = 50KB/s roughly, right?
that's not exactly a huge workload, and with the socket buffers in there
acting as a little bit of elastic for you, you're not exactly a hard realtime
app... you could probably do this with a single kthread doing the work
and not even worry about a pool in this case.

glen