On Thu, Oct 10, 2013 at 10:12 PM, Tollef Fog Heen <tfh...@err.no> wrote: > I'd go with something how it's done in Varnish: Have an (or n) > acceptor threads that schedule work to a pool of worker threads. That > scheduler should be careful about such things as treating the worker > threads as LIFO (to preserve CPU cache).
If we have systemd manage the processes as a pool, each process will run persistently and directly accept() from the inherited listener socket. This means the kernel will choose which process to wake up when a new connection comes in. This is stampede-free in modern Linux, but I'm not sure about the ordering of connections versus processes accept()ing them or whether busy workers can hold off on both notifications and accept()ing for a while. > The advice about only 2-3 > threads per CPU core looks excessively conservative. We're usually, and > quite happily running with a few thousand threads, no matter the number > of cores. The number of processes or threads per core shouldn't substantially affect any architecture work we're doing. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
