[systemd-devel] Early review request: socket activation bridge

David Strauss david at davidstrauss.net
Thu Oct 10 23:56:35 PDT 2013


On Thu, Oct 10, 2013 at 10:12 PM, Tollef Fog Heen <tfheen at 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
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]


More information about the systemd-devel mailing list