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
