Yep.
> One issue is dealing with asynchronous IO requests which have already
> been submitted. These are typically reads or writes from either disk
> devices or sockets known to be ready for read. Such requests are
> expected to be short lived, so we can use aio for them and expect
> reasonable scalability; even with 10000 fds, we are unlikely to have
> that many actual IOs in progress at once.
Yep.
> The completion port mechanism answers an entirely different problem.
> Given 10000 open sockets, how do we tell which ones have valid data on
> them? On a WAN, we can expect a lot of delays on many sockets, so a
> typical web proxy may well have very many open sockets but much, much
> less active readable data at any point in time.
Yep.
> Simply doing 10,000 asynchronous read()s and waiting for them to
> finish is not, I think, going to be a scalable answer to this problem.
> Having a completion port mechanism to identify incoming data avoids
> this. Using aio to actually read the data is another matter; we can
> do that quite happily and still expect reasonable scalability, because
> we don't have to queue arbitrarily large amounts of concurrent IO in
> that case.
Hopefully completion ports/readiness event queues will not prove
necessary, migrating FDs between two threads should do quite well.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu