Thanks for the reply Marc. :) I think I get the gist of what you're saying. You're advocating a few processes (up to the number of CPU cores) with user-space threads to avoid kernel context switch overhead. I already agree with that.
The benchmark tool in the Samba presentation also surprised me. It showed that processes are indeed a bit faster at various system calls, but only slightly so. Still doesn't make much sense to me though because the kernel already has to protect its data structures against concurrent accesses by multiple processes, no matter whether those processes are multithreaded as well. One exception is multithreaded Linux+ptmalloc2 malloc() which is significantly slower compared to single threaded. I'm surprised they haven't solved this problem yet, considering that tcmalloc makes multithreaded malloc() cheap by introducing per-thread caches. Wish you a happy new year! -- 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
