Feature request: ability to use libeio with multiple event loops

Hongli Lai hongli at phusion.nl
Tue Jan 3 00:05:14 CET 2012


On Mon, Jan 2, 2012 at 11:49 PM, Colin McCabe <cmccabe at alumni.cmu.edu> wrote:
> The problem is that there's no way for the programmer to distinguish
> "the data that really needs to be shared" from the data that shouldn't
> be shared between threads.  Even in C/C++, all you can do is insert
> padding and hope for the best.  And you'll never know how much to
> insert, because it's architecture specific.
>
> malloc doesn't allow you to specify which threads will be accessing
> the data.  It's quite possible that the memory you get back from
> malloc will be on the same cache line as another allocation that a
> different thread got back.  malloc implementations that use per-thread
> storage, like tcmalloc, can help a little bit here.  But even then,
> some allocations will be accessed by multiple threads, and they may
> experience false sharing with allocations that are intended to be used
> by only one thread.

For a second I was wondering what you meant when you said that there's
no way for the programmer to distinguish between the two kinds of
data. The programmer wrote the code so of course he can make a
distinction? Turned out you're talking about malloc. But you don't
have to use malloc. You can either build an allocator on top of malloc
which inserts the necessary padding, or you can use mmap which
allocates memory in pages.


> Threads do have an advantage in that you won't be loading the ELF
> binary twice, which will save some memory.  However, even when using
> multiple processes, shared libraries will only be loaded once.

Unfortunately many libraries create dirty memory regions upon load.
OpenSSL's libcrypto is responsible for about 800 KB of dirty data just
by loading the library:
http://vignatti.wordpress.com/2010/03/25/scrutinizing-x-memory-part-2-whats-taking-all-that-memory/
Lots and lots of stuff are implicitly linked to libcrypto. For example
if you use libcurl, that's an implicit dependency on libcrypto right
there (unless libcurl is compiled against GnuTLS of course).

-- 
Phusion | Ruby & Rails deployment, scaling and tuning solutions

Web: http://www.phusion.nl/
E-mail: info at phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)



More information about the libev mailing list