[systemd-devel] Setting Environment Configuration (Affinity) for Slices

Chris Bell cwbell at narmos.org
Mon Oct 19 15:49:05 PDT 2015


On 2015-10-19 14:15, Lennart Poettering wrote:
> On Mon, 19.10.15 17:37, Chris Bell (cwbell at narmos.org) wrote:
> 
>> >I was mostly wondering about the env var issue you raised...
>> >
>> >>I also think it would be convenient in some cases to be able to use the
>> >>'Nice' and 'Private{Network,Devices,etc}' directives apply to an entire
>> >>slice. That way I can use slices to control, manage, and group related
>> >>services. (Example: I'd like to manage postfix and dovecot together in
>> >>system-mail.slice. I'd like to be able to use the slice to set exec
>> >>options
>> >>for both services. Then if I add another service to system-mail.slice,
>> >>it
>> >>would also automatically be constrained by the limits set in
>> >>system-mail.slice.)
>> >
>> >Use CPUShares= as per-slice/per-service/per-scope equivalent of
>> >Nice=.
>> >
>> >PrivateXYZ= otoh is very specific to what a daemon does, it's a
>> >sandboxing feature, and sandboxes must always be adjusted to the
>> >individual daemons. I doubt that this is something to support as
>> >anything but a service-specific knob.
>> >
>> >Lennart
>> 
>> Ok, so it seems like most of what I've been trying to implement is 
>> available
>> in some form, just not how I was expecting. I'll take another look at 
>> the
>> Resource Control directives and see how to adjust them for my needs. 
>> It's
>> not as direct as I was hoping, but they seem like they'll do what I 
>> need.
>> 
>> If I have a set of services that really need to be finely controlled I
>> should probably just run them in a container, and set limits for the
>> container. Will that work as I am expecting? Will a systemd-nspawn 
>> container
>> respect CPUAffinity settings from the service override file?
> 
> CPUAffinity= is generally inherited down the process tree. Hence yes,
> this will work. But do note that processes may freely readjust ther
> own affinity using sched_setaffinity() at any time, and thus are free
> to undo the setting. Hooking up cpuset with systemd as proposed this
> is not possible anymore. Also, if you we hook up cpuset then it's easy
> to readjust the cpuset stuff dynmaically at runtime.
> 
> Lennart

Ok, I think my best shot is to readjust my strategy with resource 
management. I'm sure I can implement a solution with CPU Shares and CPU 
usage limits. It doesn't seem like the Affinity option can be enforced 
the way I had hoped, anyway.

Thanks for all the help!!

--Chris


More information about the systemd-devel mailing list