From 5cbfbf2aaac66111584798fdb38f243f8593444e Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Mon, 19 Jun 2023 13:00:29 +0200 Subject: [PATCH] man: place options in a some limited form of subsections MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Let's visually separate the options associated with cpu, io, memory, … in subsections This patch tries to be minimal. It just adds the section titles, and does minimal reordering to make sure the options on the same kind of resource are placed close to each other. --- man/systemd.resource-control.xml | 266 ++++++++++++++++++------------- 1 file changed, 158 insertions(+), 108 deletions(-) diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml index 7836834efe0..1cd0beea046 100644 --- a/man/systemd.resource-control.xml +++ b/man/systemd.resource-control.xml @@ -174,8 +174,9 @@ CPUWeight=20 DisableControllers=cpu / \ Options - Units of the types listed above can have settings - for resource control configuration: + Units of the types listed above can have settings for resource control configuration: + + CPU Accounting and Control @@ -305,29 +306,11 @@ CPUWeight=20 DisableControllers=cpu / \ - - AllowedMemoryNodes= - StartupAllowedMemoryNodes= + - - These settings control the controller in the unified hierarchy. + Memory Accounting and Control - Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices - or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper - NUMA nodes indices separated by a dash. - - Setting AllowedMemoryNodes= or StartupAllowedMemoryNodes= doesn't - guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. - The effective configuration is reported as EffectiveMemoryNodes=. - - While StartupAllowedMemoryNodes= applies to the startup and shutdown phases of the system, - AllowedMemoryNodes= applies to normal runtime of the system, and if the former is not set also to - the startup and shutdown phases. Using StartupAllowedMemoryNodes= allows prioritizing specific services at - boot-up and shutdown differently than during normal runtime. - - This setting is supported only with the unified control group hierarchy. - - + MemoryAccounting= @@ -492,6 +475,36 @@ CPUWeight=20 DisableControllers=cpu / \ + + AllowedMemoryNodes= + StartupAllowedMemoryNodes= + + + These settings control the controller in the unified hierarchy. + + Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices + or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper + NUMA nodes indices separated by a dash. + + Setting AllowedMemoryNodes= or StartupAllowedMemoryNodes= doesn't + guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. + The effective configuration is reported as EffectiveMemoryNodes=. + + While StartupAllowedMemoryNodes= applies to the startup and shutdown phases of the system, + AllowedMemoryNodes= applies to normal runtime of the system, and if the former is not set also to + the startup and shutdown phases. Using StartupAllowedMemoryNodes= allows prioritizing specific services at + boot-up and shutdown differently than during normal runtime. + + This setting is supported only with the unified control group hierarchy. + + + + + + Process Accounting and Control + + + TasksAccounting= @@ -529,6 +542,12 @@ CPUWeight=20 DisableControllers=cpu / \ + + + IO Accounting and Control + + + IOAccounting= @@ -665,6 +684,12 @@ CPUWeight=20 DisableControllers=cpu / \ + + + Network Accounting and Control + + + IPAccounting= @@ -791,91 +816,6 @@ CPUWeight=20 DisableControllers=cpu / \ - - IPIngressFilterPath=BPF_FS_PROGRAM_PATH - IPEgressFilterPath=BPF_FS_PROGRAM_PATH - - - Add custom network traffic filters implemented as BPF programs, applying to all IP packets - sent and received over AF_INET and AF_INET6 sockets. - Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). - - - The filters configured with this option are applied to all sockets created by processes - of this unit (or in the case of socket units, associated with it). The filters are loaded in addition - to filters any of the parent slice units this unit might be a member of as well as any - IPAddressAllow= and IPAddressDeny= filters in any of these units. - By default there are no filters specified. - - If these settings are used multiple times in the same unit all the specified programs are attached. If an - empty string is assigned to these settings the program list is reset and all previous specified programs ignored. - - If the path BPF_FS_PROGRAM_PATH in IPIngressFilterPath= assignment - is already being handled by BPFProgram= ingress hook, e.g. - BPFProgram=ingress:BPF_FS_PROGRAM_PATH, - the assignment will be still considered valid and the program will be attached to a cgroup. Same for - IPEgressFilterPath= path and egress hook. - - Note that for socket-activated services, the IP filter programs configured on the socket unit apply to - all sockets associated with it directly, but not to any sockets created by the ultimately activated services - for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into - the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both - the socket and the service unit, however it often makes sense to maintain one configuration more open and the other - one more restricted, depending on the usecase. - - Note that these settings might not be supported on some systems (for example if eBPF control group - support is not enabled in the underlying kernel or container manager). These settings will fail the service in - that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually - (requires Delegate=yes) instead of using this setting. - - - - - BPFProgram=type:program-path - - Add a custom cgroup BPF program. - - BPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. - (This generalizes the functionality exposed via IPEgressFilterPath= for egress and - IPIngressFilterPath= for ingress.) - Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach - flags determined by the unit. For details about attachment types and flags see . - For general BPF documentation please refer to . - - The specification of BPF program consists of a type followed by a - program-path with : as the separator: - type:program-path. - - type is the string name of BPF attach type also used in - bpftool. type can be one of egress, - ingress, sock_create, sock_ops, - device, bind4, bind6, - connect4, connect6, post_bind4, - post_bind6, sendmsg4, sendmsg6, - sysctl, recvmsg4, recvmsg6, - getsockopt, setsockopt. - - Setting BPFProgram= to an empty value makes previous assignments ineffective. - Multiple assignments of the same type:program-path - value have the same effect as a single assignment: the program with the path program-path - will be attached to cgroup hook type just once. - If BPF egress pinned to program-path path is already being - handled by IPEgressFilterPath=, BPFProgram= - assignment will be considered valid and BPFProgram= will be attached to a cgroup. - Similarly for ingress hook and IPIngressFilterPath= assignment. - - BPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF - attach flag multi, that allows further attachments of the same - type within cgroup hierarchy topped by the unit cgroup. - - Examples: -BPFProgram=egress:/sys/fs/bpf/egress-hook -BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook - - - - SocketBindAllow=bind-rule SocketBindDeny=bind-rule @@ -1017,6 +957,103 @@ RestrictNetworkInterfaces=~eth1 + + + BPF Programs + + + + + IPIngressFilterPath=BPF_FS_PROGRAM_PATH + IPEgressFilterPath=BPF_FS_PROGRAM_PATH + + + Add custom network traffic filters implemented as BPF programs, applying to all IP packets + sent and received over AF_INET and AF_INET6 sockets. + Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). + + + The filters configured with this option are applied to all sockets created by processes + of this unit (or in the case of socket units, associated with it). The filters are loaded in addition + to filters any of the parent slice units this unit might be a member of as well as any + IPAddressAllow= and IPAddressDeny= filters in any of these units. + By default there are no filters specified. + + If these settings are used multiple times in the same unit all the specified programs are attached. If an + empty string is assigned to these settings the program list is reset and all previous specified programs ignored. + + If the path BPF_FS_PROGRAM_PATH in IPIngressFilterPath= assignment + is already being handled by BPFProgram= ingress hook, e.g. + BPFProgram=ingress:BPF_FS_PROGRAM_PATH, + the assignment will be still considered valid and the program will be attached to a cgroup. Same for + IPEgressFilterPath= path and egress hook. + + Note that for socket-activated services, the IP filter programs configured on the socket unit apply to + all sockets associated with it directly, but not to any sockets created by the ultimately activated services + for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into + the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both + the socket and the service unit, however it often makes sense to maintain one configuration more open and the other + one more restricted, depending on the usecase. + + Note that these settings might not be supported on some systems (for example if eBPF control group + support is not enabled in the underlying kernel or container manager). These settings will fail the service in + that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually + (requires Delegate=yes) instead of using this setting. + + + + + BPFProgram=type:program-path + + Add a custom cgroup BPF program. + + BPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. + (This generalizes the functionality exposed via IPEgressFilterPath= for egress and + IPIngressFilterPath= for ingress.) + Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach + flags determined by the unit. For details about attachment types and flags see . + For general BPF documentation please refer to . + + The specification of BPF program consists of a type followed by a + program-path with : as the separator: + type:program-path. + + type is the string name of BPF attach type also used in + bpftool. type can be one of egress, + ingress, sock_create, sock_ops, + device, bind4, bind6, + connect4, connect6, post_bind4, + post_bind6, sendmsg4, sendmsg6, + sysctl, recvmsg4, recvmsg6, + getsockopt, setsockopt. + + Setting BPFProgram= to an empty value makes previous assignments ineffective. + Multiple assignments of the same type:program-path + value have the same effect as a single assignment: the program with the path program-path + will be attached to cgroup hook type just once. + If BPF egress pinned to program-path path is already being + handled by IPEgressFilterPath=, BPFProgram= + assignment will be considered valid and BPFProgram= will be attached to a cgroup. + Similarly for ingress hook and IPIngressFilterPath= assignment. + + BPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF + attach flag multi, that allows further attachments of the same + type within cgroup hierarchy topped by the unit cgroup. + + Examples: +BPFProgram=egress:/sys/fs/bpf/egress-hook +BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook + + + + + + + Device Access + + + DeviceAllow= @@ -1116,6 +1153,12 @@ DeviceAllow=/dev/loop-control + + + Control Group Management + + + Slice= @@ -1234,6 +1277,12 @@ DeviceAllow=/dev/loop-control + + + Memory Pressure Control + + + ManagedOOMSwap=auto|kill ManagedOOMMemoryPressure=auto|kill @@ -1367,6 +1416,7 @@ DeviceAllow=/dev/loop-control details on the permitted syntax. +