-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 16, 2010 at 01:19:01PM -0400, Frank Cusack wrote:
[...]
And when you don't want to block on I/O. Threads are almost always
easier than AIO, and especially easy (ie, no scary complexity issues
eg deadlock) if you aren't sharing data
Timo Sirainen put forth on 3/14/2010 6:46 AM:
- open file 1
- read contents of file 1
- open file 2
- read contents of file 2
- ..etc..
All of this when processing a single client connection's command(s). And
while waiting for I/O replies Dovecot can do other work. So user sees
Jakob Hirsch put forth on 3/16/2010 3:55 AM:
Stan Hoeppner, 2010-03-16 08:45:
Regarding memory usage, on Linux anyway, you should really read this Timo.
It would be mutually beneficial to Dovecot (and Postfix, and etc). I've not
played with it yet, and I don't have a busy server to test it
On Tue, 2010-03-16 at 11:16 +0100, Steffen Kaiser wrote:
If I display a process map of an active imap process, I have:
mapped: 2656Kwriteable/private: 460Kshared: 300K
Essentially you are talking about 460KB of KSM-able data.
IMHO, all modern Unix-alike system just map code pages
On Tue, 2010-03-16 at 02:45 -0500, Stan Hoeppner wrote:
Concentrate on rewriting imapd into a threaded model, and get it right.
I could give a lot of reasons for this, but: no.
signature.asc
Description: This is a digitally signed message part
Steffen Kaiser put forth on 3/16/2010 5:16 AM:
The paste talks about data.
You talk about code.
The author's use of the word data in that sentence was obviously not in
the programmatic context but in the bit bucket context. In many contexts,
the word data can properly describe the entire
Stan Hoeppner, 2010-03-16 10:50:
AFAIK, KSM is primarily useful for vservers (xen, kvm etc.) running the
same software. How would running a single instance of dovecot (or any
other daemon) profit by that? AFAICS, generates many instances of the
same data does not apply to dovecot (or most
On 16/03/2010 12:31, Stan Hoeppner wrote:
IMHO, all modern Unix-alike system just map code pages read-only into
the process and share them among all processes. No KSM required at all.
If this were the case with Linux then the KSM project would have never been
initiated? You attribute
Timo Sirainen put forth on 3/16/2010 6:36 AM:
On Tue, 2010-03-16 at 11:16 +0100, Steffen Kaiser wrote:
If I display a process map of an active imap process, I have:
mapped: 2656Kwriteable/private: 460Kshared: 300K
Essentially you are talking about 460KB of KSM-able data.
IMHO, all
Timo Sirainen put forth on 3/16/2010 6:37 AM:
On Tue, 2010-03-16 at 02:45 -0500, Stan Hoeppner wrote:
Concentrate on rewriting imapd into a threaded model, and get it right.
I could give a lot of reasons for this, but: no.
Ok, what am I missing? Given the current clone/fork imap
On Tue, 2010-03-16 at 10:55 -0500, Stan Hoeppner wrote:
Timo Sirainen put forth on 3/16/2010 6:37 AM:
On Tue, 2010-03-16 at 02:45 -0500, Stan Hoeppner wrote:
Concentrate on rewriting imapd into a threaded model, and get it right.
I could give a lot of reasons for this, but: no.
Ok,
On 3/16/10 6:44 PM +0200 Timo Sirainen wrote:
Threads are useful when you need to do CPU intensive work in parallel,
and threads need access to shared data structures.
And when you don't want to block on I/O. Threads are almost always
easier than AIO, and especially easy (ie, no scary
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
On Tue, 2010-03-16 at 13:19 -0400, Frank Cusack wrote:
On 3/16/10 6:44 PM +0200 Timo Sirainen wrote:
Threads are useful when you need to do CPU intensive work in parallel,
and threads need access to shared data structures.
And when you don't want to block on I/O. Threads are almost always
On Tue, 2010-03-16 at 13:30 -0400, Frank Cusack wrote:
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
Each one is over 2MB in size, and all of those imap processes share close
to 2MB of memory pages that are identical, because the code is identical.
You may wish to learn how shared text works, I guess. Or do I miss something?
Did the Penguins do away with shared text?
handle = open(path, mode)
- this function can't fail. it's executed asynchronously.
Does that mean you can successfully open(/nonexistent, mode); write() to it
over and over again and only the commit() fails?
handle = create(path, mode, permissions)
[...]
- mode=fail-if-exists: commit()
On 15.3.2010, at 21.37, Edgar Fuß wrote:
handle = open(path, mode)
- this function can't fail. it's executed asynchronously.
Does that mean you can successfully open(/nonexistent, mode); write() to it
over and over again and only the commit() fails?
Probably. But in mdbox case you lock the
No, commit actually. create() is asynchronous.
Silly me.
I mean it's going to use fcntl() or whatever OS locking (as opposed
to some slow remote locking with remote storages).
But fcntl() will use NLM if the file is on NFS.
I tried a few Google searches first, but I didn't then find anything
On 14.3.2010, at 13.46, Timo Sirainen wrote:
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.)
..
That's kind of the point. You could have
On 15.3.2010, at 22.05, Edgar Fuß wrote:
I mean it's going to use fcntl() or whatever OS locking (as opposed
to some slow remote locking with remote storages).
But fcntl() will use NLM if the file is on NFS.
Yeah, and that's why multi-dbox probably isn't a good idea with NFS.
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
The long term plan is to get all of Dovecot disk I/O asynchronous. The
first step to that direction would be to make dbox/mdbox I/O
asynchronous. This might also allow mbox/maildir to become partially
asynchronous.
http://www.dovecot.org/list/dovecot/2009-December/045481.html already
started
On 3/14/10 1:59 AM +0200 Timo Sirainen wrote:
The long term plan is to get all of Dovecot disk I/O asynchronous. The
first step to that direction would be to make dbox/mdbox I/O
asynchronous. This might also allow mbox/maildir to become partially
asynchronous.
Does it really need to be? Sure,
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
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
26 matches
Mail list logo
