mirror of
https://github.com/torvalds/linux.git
synced 2026-07-27 09:36:22 +02:00
cgroup: Fixes for v7.2-rc3
- A cpuset that never set its memory nodes could divide by zero when a task's mempolicy rebinds on CPU hotplug. Rebind against the effective nodes, which are always populated. - Documentation fixes for memory.stat, io.stat, and the misc and v1 RDMA controllers. -----BEGIN PGP SIGNATURE----- iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCalVWkg4cdGpAa2VybmVs Lm9yZwAKCRCxYfJx3gVYGet9AQD3/qE93E+PctxXa+rmRfSSjIzqqv9NUZa4THjs YOUqSAEApVSLPkhg3xHF61q9l+FuocLLY378Uf6LYGWet1SghAQ= =1Gp+ -----END PGP SIGNATURE----- Merge tag 'cgroup-for-7.2-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - A cpuset that never set its memory nodes could divide by zero when a task's mempolicy rebinds on CPU hotplug. Rebind against the effective nodes, which are always populated - Documentation fixes for memory.stat, io.stat, and the misc and v1 RDMA controllers * tag 'cgroup-for-7.2-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: Docs/admin-guide/cgroup-v2: note blkcg_debug_stats gates io.latency stats Docs/admin-guide/cgroup-v1: document rdma.peak, rdma.events and rdma.events.local Docs/admin-guide/cgroup-v2: drop stale misc interface file count cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Docs/admin-guide/cgroup-v2: fix memory.stat doc details
This commit is contained in:
Linus Torvalds
commit
3b029c035b
|
|
@ -9,6 +9,7 @@ RDMA Controller
|
|||
1-2. Why RDMA controller needed?
|
||||
1-3. How is RDMA controller implemented?
|
||||
2. Usage Examples
|
||||
3. RDMA Interface Files
|
||||
|
||||
1. Overview
|
||||
===========
|
||||
|
|
@ -115,3 +116,68 @@ Following resources can be accounted by rdma controller.
|
|||
(d) Delete resource limit::
|
||||
|
||||
echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
|
||||
|
||||
3. RDMA Interface Files
|
||||
========================
|
||||
|
||||
The following interface files are available in each non-root RDMA cgroup.
|
||||
|
||||
rdma.max
|
||||
A read-write file which describes the configured resource limit
|
||||
for an RDMA/IB device. See the Usage Examples above.
|
||||
|
||||
rdma.current
|
||||
A read-only file which describes the current resource usage.
|
||||
|
||||
rdma.peak
|
||||
A read-only nested-keyed file which shows the historical high
|
||||
watermark of resource usage per device since the cgroup was created.
|
||||
|
||||
An example for mlx4 and ocrdma device follows::
|
||||
|
||||
mlx4_0 hca_handle=1 hca_object=20
|
||||
ocrdma1 hca_handle=0 hca_object=23
|
||||
|
||||
rdma.events
|
||||
A read-only nested-keyed file which exists on non-root cgroups
|
||||
and contains the following keys:
|
||||
|
||||
max
|
||||
The number of times a process in this cgroup or its
|
||||
descendants attempted an RDMA resource allocation that
|
||||
was rejected because a rdma.max limit in the subtree
|
||||
was reached. This is a hierarchical counter propagated
|
||||
upward to all ancestor cgroups. A value change in this
|
||||
file generates a file modified event.
|
||||
|
||||
alloc_fail
|
||||
The number of RDMA resource allocation attempts that
|
||||
originated in this cgroup or its descendants and failed
|
||||
due to a rdma.max limit being reached. This is a
|
||||
hierarchical counter propagated upward.
|
||||
|
||||
An example for mlx4 device follows::
|
||||
|
||||
mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=3 hca_object.max=0 hca_object.alloc_fail=0
|
||||
|
||||
rdma.events.local
|
||||
Similar to rdma.events but the fields are local to the cgroup,
|
||||
i.e. not hierarchical. The file modified event generated on this
|
||||
file reflects only the local events.
|
||||
|
||||
The following nested keys are defined.
|
||||
|
||||
max
|
||||
The number of times a process in this cgroup or its
|
||||
descendants attempted an RDMA resource allocation that
|
||||
was rejected because this cgroup's own rdma.max limit
|
||||
was reached.
|
||||
|
||||
alloc_fail
|
||||
The number of RDMA resource allocation attempts
|
||||
originating from this cgroup that failed due to this
|
||||
cgroup's or an ancestor's rdma.max limit.
|
||||
|
||||
An example for mlx4 device follows::
|
||||
|
||||
mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=0 hca_object.max=0 hca_object.alloc_fail=0
|
||||
|
|
|
|||
|
|
@ -1570,7 +1570,7 @@ The following nested keys are defined.
|
|||
sock (npn)
|
||||
Amount of memory used in network transmission buffers
|
||||
|
||||
vmalloc (npn)
|
||||
vmalloc
|
||||
Amount of memory used for vmap backed memory.
|
||||
|
||||
shmem
|
||||
|
|
@ -1735,7 +1735,7 @@ The following nested keys are defined.
|
|||
Number of pages written from zswap to swap.
|
||||
|
||||
zswap_incomp
|
||||
Number of incompressible pages currently stored in zswap
|
||||
Amount of memory used by incompressible pages currently stored in zswap
|
||||
without compression. These pages could not be compressed to
|
||||
a size smaller than PAGE_SIZE, so they are stored as-is.
|
||||
|
||||
|
|
@ -2257,10 +2257,11 @@ groups D and F will influence each other. Group G will influence nobody::
|
|||
So the ideal way to configure this is to set io.latency in groups A, B, and C.
|
||||
Generally you do not want to set a value lower than the latency your device
|
||||
supports. Experiment to find the value that works best for your workload.
|
||||
Start at higher than the expected latency for your device and watch the
|
||||
avg_lat value in io.stat for your workload group to get an idea of the
|
||||
latency you see during normal operation. Use the avg_lat value as a basis for
|
||||
your real setting, setting at 10-15% higher than the value in io.stat.
|
||||
Start at higher than the expected latency for your device and, with
|
||||
blkcg_debug_stats enabled, watch the avg_lat value in io.stat for your
|
||||
workload group to get an idea of the latency you see during normal operation.
|
||||
Use the avg_lat value as a basis for your real setting, setting at 10-15%
|
||||
higher than the value in io.stat.
|
||||
|
||||
How IO Latency Throttling Works
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -2298,7 +2299,9 @@ IO Latency Interface Files
|
|||
|
||||
io.stat
|
||||
If the controller is enabled you will see extra stats in io.stat in
|
||||
addition to the normal ones.
|
||||
addition to the normal ones. These debug stats are only emitted when
|
||||
the blkcg_debug_stats module parameter is enabled (it is disabled by
|
||||
default).
|
||||
|
||||
depth
|
||||
This is the current queue depth for the group.
|
||||
|
|
@ -2934,7 +2937,8 @@ include/linux/misc_cgroup.h.
|
|||
Misc Interface Files
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then:
|
||||
Miscellaneous controller provides the following interface files. If two misc
|
||||
resources (res_a and res_b) are registered then:
|
||||
|
||||
misc.capacity
|
||||
A read-only flat-keyed file shown only in the root cgroup. It shows
|
||||
|
|
|
|||
|
|
@ -2653,7 +2653,12 @@ void cpuset_update_tasks_nodemask(struct cpuset *cs)
|
|||
|
||||
migrate = is_memory_migrate(cs);
|
||||
|
||||
mpol_rebind_mm(mm, &cs->mems_allowed);
|
||||
/*
|
||||
* For v1 we can have empty effective_mems, but we cannot
|
||||
* attach any tasks (see cpuset_can_attach_check()). For v2,
|
||||
* effective_mems is guaranteed to not be empty.
|
||||
*/
|
||||
mpol_rebind_mm(mm, &cs->effective_mems);
|
||||
if (migrate)
|
||||
cpuset_migrate_mm(mm, &cs->old_mems_allowed, &newmems);
|
||||
else
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user