[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