-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
> 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?
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, doveco
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
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 th
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 complexi
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:
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 para
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.
>>
>>
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
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
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 enti
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
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 pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 16 Mar 2010, Stan Hoeppner wrote:
You didn't read the paste Jakob. Or maybe you don't comprehend the
material? Also, it seems you're unaware that Dovecot creates at minimum 1
imap process per client connection. In the case of Thunderbird,
Jakob Hirsch put forth on 3/16/2010 3:55 AM:
> AFAICS, "generates many instances of the
> same data" does not apply to dovecot (or most other deamons).
You're misreading the meaning of the word "data" in this context. In this
context "data" simply means memory page contents, not "program data
str
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 t
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, but I'm
> betting it would seriously bene
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 s
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 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 h
> 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 anyth
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 lo
> 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 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
>>> yo
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 actual
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 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,
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 descr
29 matches
Mail list logo
