On Mon, Jan 2, 2012 at 11:49 PM, Colin McCabe <[email protected]> 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: [email protected] Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
