On 3/14/10 1:46 PM +0200 Timo Sirainen wrote:
On 14.3.2010, at 5.27, Frank Cusack wrote:
On 3/14/10 4:48 AM +0200 Timo Sirainen wrote:
On 14.3.2010, at 4.40, Frank Cusack wrote:
Just playing devil's advocate since you haven't presented the advantage of async I/O. I don't want to guess at the reasoning, but e.g. I hope you're not planning to return success results before I/O actually completes.
The idea was that a single process could handle tons of connections.
And what's the advantage of that? process-per-client already scales really well, at the expense of more memory. In both Linux and Solaris, the cost of a process context switch is nearly the same as a thread context switch. I don't know about *BSD but I imagine it's similar.
Well, you just mentioned the benefits :) Less memory usage, less context switches (of any kind). (You aren't assuming I'd do something like one thread per connection, right? That's not going to happen.)
But as I stated, dovecot is likely to be I/O limited, not CPU or memory limited. Who cares if there is 10% less memory usage when the limit is still I/O? Feel free to trout-slap me (to borrow from Stan) if you expect dovecot to be memory limited.
That's kind of the point. You could have just a few IMAP processes where each can handle hundreds of connections. Currently that's not a very good idea, because a single connection that waits on disk I/O blocks all the other connections in the same process from doing anything.
Or you could have a whole bunch of IMAP processes, one per connection. All you're doing is multiplexing the I/O at a different part of your system. Each connection doesn't share any state or other data with other "related" connections so it doesn't matter how you multiplex the I/O, since any imagined efficiency from AIO/threads isn't going to be realized due to I/O saturation before CPU saturation.
Kernel can only parallelize requests from different processes.
Right, but again so what? Since each connection is a different process, all I/O is parallelized in dovecot's case. It works well because connections aren't related to each other.
-frank