요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Memory controls
cpusets.rst:261-388Direct-reclaim pressure metric과 page-cache memory spread를 다룹니다.
Scheduler domains
cpusets.rst:389-615Load-balance domain partition과 event search relax level을 설명합니다.
Placement changes and usage
cpusets.rst:616-884CPU·memory update timing, page migration, hotplug 예외와 실제 filesystem syntax를 정리합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
.. _cpusets:
3
=======
4
CPUSETS
5
=======
7
Copyright (C) 2004 BULL SA.
9
Written by [email protected]
11
- Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
12
- Modified by Paul Jackson <[email protected]>
13
- Modified by Christoph Lameter <[email protected]>
14
- Modified by Paul Menage <[email protected]>
15
- Modified by Hidetoshi Seto <[email protected]>
17
.. CONTENTS:
19
1. Cpusets
20
1.1 What are cpusets ?
21
1.2 Why are cpusets needed ?
22
1.3 How are cpusets implemented ?
23
1.4 What are exclusive cpusets ?
24
1.5 What is memory_pressure ?
25
1.6 What is memory spread ?
26
1.7 What is sched_load_balance ?
27
1.8 What is sched_relax_domain_level ?
28
1.9 How do I use cpusets ?
29
2. Usage Examples and Syntax
30
2.1 Basic Usage
31
2.2 Adding/removing cpus
32
2.3 Setting flags
33
2.4 Attaching processes
34
3. Questions
35
4. Contact
37
1. Cpusets
38
==========
40
1.1 What are cpusets ?
41
----------------------
43
Cpusets provide a mechanism for assigning a set of CPUs and Memory
44
Nodes to a set of tasks. In this document "Memory Node" refers to
45
an on-line node that contains memory.
47
Cpusets constrain the CPU and Memory placement of tasks to only
48
the resources within a task's current cpuset. They form a nested
49
hierarchy visible in a virtual file system. These are the essential
50
hooks, beyond what is already present, required to manage dynamic
51
job placement on large systems.
53
Cpusets use the generic cgroup subsystem described in
54
Documentation/admin-guide/cgroup-v1/cgroups.rst.
56
Requests by a task, using the sched_setaffinity(2) system call to
57
include CPUs in its CPU affinity mask, and using the mbind(2) and
58
set_mempolicy(2) system calls to include Memory Nodes in its memory
59
policy, are both filtered through that task's cpuset, filtering out any
60
CPUs or Memory Nodes not in that cpuset. The scheduler will not
61
schedule a task on a CPU that is not allowed in its cpus_allowed
62
vector, and the kernel page allocator will not allocate a page on a
63
node that is not allowed in the requesting task's mems_allowed vector.
65
User level code may create and destroy cpusets by name in the cgroup
66
virtual file system, manage the attributes and permissions of these
67
cpusets and which CPUs and Memory Nodes are assigned to each cpuset,
68
specify and query to which cpuset a task is assigned, and list the
69
task pids assigned to a cpuset.
72
1.2 Why are cpusets needed ?
73
----------------------------
75
The management of large computer systems, with many processors (CPUs),
76
complex memory cache hierarchies and multiple Memory Nodes having
77
non-uniform access times (NUMA) presents additional challenges for
78
the efficient scheduling and memory placement of processes.
80
Frequently more modest sized systems can be operated with adequate
81
efficiency just by letting the operating system automatically share
82
the available CPU and Memory resources amongst the requesting tasks.
84
But larger systems, which benefit more from careful processor and
85
memory placement to reduce memory access times and contention,
86
and which typically represent a larger investment for the customer,
87
can benefit from explicitly placing jobs on properly sized subsets of
88
the system.
90
This can be especially valuable on:
92
* Web Servers running multiple instances of the same web application,
93
* Servers running different applications (for instance, a web server
94
and a database), or
95
* NUMA systems running large HPC applications with demanding
96
performance characteristics.
98
These subsets, or "soft partitions" must be able to be dynamically
99
adjusted, as the job mix changes, without impacting other concurrently
100
executing jobs. The location of the running jobs pages may also be moved
101
when the memory locations are changed.
103
The kernel cpuset patch provides the minimum essential kernel
104
mechanisms required to efficiently implement such subsets. It
105
leverages existing CPU and Memory Placement facilities in the Linux
106
kernel to avoid any additional impact on the critical scheduler or
107
memory allocator code.
110
1.3 How are cpusets implemented ?
111
---------------------------------
113
Cpusets provide a Linux kernel mechanism to constrain which CPUs and
114
Memory Nodes are used by a process or set of processes.
116
The Linux kernel already has a pair of mechanisms to specify on which
117
CPUs a task may be scheduled (sched_setaffinity) and on which Memory
118
Nodes it may obtain memory (mbind, set_mempolicy).
120
Cpusets extends these two mechanisms as follows:
122
- Cpusets are sets of allowed CPUs and Memory Nodes, known to the
123
kernel.
124
- Each task in the system is attached to a cpuset, via a pointer
125
in the task structure to a reference counted cgroup structure.
126
- Calls to sched_setaffinity are filtered to just those CPUs
127
allowed in that task's cpuset.
128
- Calls to mbind and set_mempolicy are filtered to just
129
those Memory Nodes allowed in that task's cpuset.
130
- The root cpuset contains all the systems CPUs and Memory
131
Nodes.
132
- For any cpuset, one can define child cpusets containing a subset
133
of the parents CPU and Memory Node resources.
134
- The hierarchy of cpusets can be mounted at /dev/cpuset, for
135
browsing and manipulation from user space.
136
- A cpuset may be marked exclusive, which ensures that no other
137
cpuset (except direct ancestors and descendants) may contain
138
any overlapping CPUs or Memory Nodes.
139
- You can list all the tasks (by pid) attached to any cpuset.
141
The implementation of cpusets requires a few, simple hooks
142
into the rest of the kernel, none in performance critical paths:
144
- in init/main.c, to initialize the root cpuset at system boot.
145
- in fork and exit, to attach and detach a task from its cpuset.
146
- in sched_setaffinity, to mask the requested CPUs by what's
147
allowed in that task's cpuset.
148
- in sched.c migrate_live_tasks(), to keep migrating tasks within
149
the CPUs allowed by their cpuset, if possible.
150
- in the mbind and set_mempolicy system calls, to mask the requested
151
Memory Nodes by what's allowed in that task's cpuset.
152
- in page_alloc.c, to restrict memory to allowed nodes.
153
- in vmscan.c, to restrict page recovery to the current cpuset.
155
You should mount the "cgroup" filesystem type in order to enable
156
browsing and modifying the cpusets presently known to the kernel. No
157
new system calls are added for cpusets - all support for querying and
158
modifying cpusets is via this cpuset file system.
160
The /proc/<pid>/status file for each task has four added lines,
161
displaying the task's cpus_allowed (on which CPUs it may be scheduled)
162
and mems_allowed (on which Memory Nodes it may obtain memory),
163
in the two formats seen in the following example::
165
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff
166
Cpus_allowed_list: 0-127
167
Mems_allowed: ffffffff,ffffffff
168
Mems_allowed_list: 0-63
170
Each cpuset is represented by a directory in the cgroup file system
171
containing (on top of the standard cgroup files) the following
172
files describing that cpuset:
174
- cpuset.cpus: list of CPUs in that cpuset
175
- cpuset.mems: list of Memory Nodes in that cpuset
176
- cpuset.memory_migrate flag: if set, move pages to cpusets nodes
177
- cpuset.cpu_exclusive flag: is cpu placement exclusive?
178
- cpuset.mem_exclusive flag: is memory placement exclusive?
179
- cpuset.mem_hardwall flag: is memory allocation hardwalled
180
- cpuset.memory_pressure: measure of how much paging pressure in cpuset
181
- cpuset.memory_spread_page flag: if set, spread page cache evenly on allowed nodes
182
- cpuset.memory_spread_slab flag: OBSOLETE. Doesn't have any function.
183
- cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset
184
- cpuset.sched_relax_domain_level: the searching range when migrating tasks
186
In addition, only the root cpuset has the following file:
188
- cpuset.memory_pressure_enabled flag: compute memory_pressure?
190
New cpusets are created using the mkdir system call or shell
191
command. The properties of a cpuset, such as its flags, allowed
192
CPUs and Memory Nodes, and attached tasks, are modified by writing
193
to the appropriate file in that cpusets directory, as listed above.
195
The named hierarchical structure of nested cpusets allows partitioning
196
a large system into nested, dynamically changeable, "soft-partitions".
198
The attachment of each task, automatically inherited at fork by any
199
children of that task, to a cpuset allows organizing the work load
200
on a system into related sets of tasks such that each set is constrained
201
to using the CPUs and Memory Nodes of a particular cpuset. A task
202
may be re-attached to any other cpuset, if allowed by the permissions
203
on the necessary cpuset file system directories.
205
Such management of a system "in the large" integrates smoothly with
206
the detailed placement done on individual tasks and memory regions
207
using the sched_setaffinity, mbind and set_mempolicy system calls.
209
The following rules apply to each cpuset:
211
- Its CPUs and Memory Nodes must be a subset of its parents.
212
- It can't be marked exclusive unless its parent is.
213
- If its cpu or memory is exclusive, they may not overlap any sibling.
215
These rules, and the natural hierarchy of cpusets, enable efficient
216
enforcement of the exclusive guarantee, without having to scan all
217
cpusets every time any of them change to ensure nothing overlaps a
218
exclusive cpuset. Also, the use of a Linux virtual file system (vfs)
219
to represent the cpuset hierarchy provides for a familiar permission
220
and name space for cpusets, with a minimum of additional kernel code.
222
The cpus and mems files in the root (top_cpuset) cpuset are
223
read-only. The cpus file automatically tracks the value of
224
cpu_online_mask using a CPU hotplug notifier, and the mems file
225
automatically tracks the value of node_states[N_MEMORY]--i.e.,
226
nodes with memory--using the cpuset_track_online_nodes() hook.
228
The cpuset.effective_cpus and cpuset.effective_mems files are
229
normally read-only copies of cpuset.cpus and cpuset.mems files
230
respectively. If the cpuset cgroup filesystem is mounted with the
231
special "cpuset_v2_mode" option, the behavior of these files will become
232
similar to the corresponding files in cpuset v2. In other words, hotplug
233
events will not change cpuset.cpus and cpuset.mems. Those events will
234
only affect cpuset.effective_cpus and cpuset.effective_mems which show
235
the actual cpus and memory nodes that are currently used by this cpuset.
236
See Documentation/admin-guide/cgroup-v2.rst for more information about
237
cpuset v2 behavior.
240
1.4 What are exclusive cpusets ?
241
--------------------------------
243
If a cpuset is cpu or mem exclusive, no other cpuset, other than
244
a direct ancestor or descendant, may share any of the same CPUs or
245
Memory Nodes.
247
A cpuset that is cpuset.mem_exclusive *or* cpuset.mem_hardwall is "hardwalled",
248
i.e. it restricts kernel allocations for page, buffer and other data
249
commonly shared by the kernel across multiple users. All cpusets,
250
whether hardwalled or not, restrict allocations of memory for user
251
space. This enables configuring a system so that several independent
252
jobs can share common kernel data, such as file system pages, while
253
isolating each job's user allocation in its own cpuset. To do this,
254
construct a large mem_exclusive cpuset to hold all the jobs, and
255
construct child, non-mem_exclusive cpusets for each individual job.
256
Only a small amount of typical kernel memory, such as requests from
257
interrupt handlers, is allowed to be taken outside even a
258
mem_exclusive cpuset.
261
1.5 What is memory_pressure ?
262
-----------------------------
263
The memory_pressure of a cpuset provides a simple per-cpuset metric
264
of the rate that the tasks in a cpuset are attempting to free up in
265
use memory on the nodes of the cpuset to satisfy additional memory
266
requests.
268
This enables batch managers monitoring jobs running in dedicated
269
cpusets to efficiently detect what level of memory pressure that job
270
is causing.
272
This is useful both on tightly managed systems running a wide mix of
273
submitted jobs, which may choose to terminate or re-prioritize jobs that
274
are trying to use more memory than allowed on the nodes assigned to them,
275
and with tightly coupled, long running, massively parallel scientific
276
computing jobs that will dramatically fail to meet required performance
277
goals if they start to use more memory than allowed to them.
279
This mechanism provides a very economical way for the batch manager
280
to monitor a cpuset for signs of memory pressure. It's up to the
281
batch manager or other user code to decide what to do about it and
282
take action.
284
==>
285
Unless this feature is enabled by writing "1" to the special file
286
/dev/cpuset/memory_pressure_enabled, the hook in the rebalance
287
code of __alloc_pages() for this metric reduces to simply noticing
288
that the cpuset_memory_pressure_enabled flag is zero. So only
289
systems that enable this feature will compute the metric.
291
Why a per-cpuset, running average:
293
Because this meter is per-cpuset, rather than per-task or mm,
294
the system load imposed by a batch scheduler monitoring this
295
metric is sharply reduced on large systems, because a scan of
296
the tasklist can be avoided on each set of queries.
298
Because this meter is a running average, instead of an accumulating
299
counter, a batch scheduler can detect memory pressure with a
300
single read, instead of having to read and accumulate results
301
for a period of time.
303
Because this meter is per-cpuset rather than per-task or mm,
304
the batch scheduler can obtain the key information, memory
305
pressure in a cpuset, with a single read, rather than having to
306
query and accumulate results over all the (dynamically changing)
307
set of tasks in the cpuset.
309
A per-cpuset simple digital filter (requires a spinlock and 3 words
310
of data per-cpuset) is kept, and updated by any task attached to that
311
cpuset, if it enters the synchronous (direct) page reclaim code.
313
A per-cpuset file provides an integer number representing the recent
314
(half-life of 10 seconds) rate of direct page reclaims caused by
315
the tasks in the cpuset, in units of reclaims attempted per second,
316
times 1000.
319
1.6 What is memory spread ?
320
---------------------------
321
There are two boolean flag files per cpuset that control where the
322
kernel allocates pages for the file system buffers and related in
323
kernel data structures. They are called 'cpuset.memory_spread_page' and
324
'cpuset.memory_spread_slab'.
326
If the per-cpuset boolean flag file 'cpuset.memory_spread_page' is set, then
327
the kernel will spread the file system buffers (page cache) evenly
328
over all the nodes that the faulting task is allowed to use, instead
329
of preferring to put those pages on the node where the task is running.
331
If the per-cpuset boolean flag file 'cpuset.memory_spread_slab' is set,
332
then the kernel will spread some file system related slab caches,
333
such as for inodes and dentries evenly over all the nodes that the
334
faulting task is allowed to use, instead of preferring to put those
335
pages on the node where the task is running.
337
The setting of these flags does not affect anonymous data segment or
338
stack segment pages of a task.
340
By default, both kinds of memory spreading are off, and memory
341
pages are allocated on the node local to where the task is running,
342
except perhaps as modified by the task's NUMA mempolicy or cpuset
343
configuration, so long as sufficient free memory pages are available.
345
When new cpusets are created, they inherit the memory spread settings
346
of their parent.
348
Setting memory spreading causes allocations for the affected page
349
or slab caches to ignore the task's NUMA mempolicy and be spread
350
instead. Tasks using mbind() or set_mempolicy() calls to set NUMA
351
mempolicies will not notice any change in these calls as a result of
352
their containing task's memory spread settings. If memory spreading
353
is turned off, then the currently specified NUMA mempolicy once again
354
applies to memory page allocations.
356
Both 'cpuset.memory_spread_page' and 'cpuset.memory_spread_slab' are boolean flag
357
files. By default they contain "0", meaning that the feature is off
358
for that cpuset. If a "1" is written to that file, then that turns
359
the named feature on.
361
The implementation is simple.
363
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
364
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
365
joins that cpuset. The page allocation calls for the page cache
366
is modified to perform an inline check for this PFA_SPREAD_PAGE task
367
flag, and if set, a call to a new routine cpuset_mem_spread_node()
368
returns the node to prefer for the allocation.
370
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
371
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
372
pages from the node returned by cpuset_mem_spread_node().
374
The cpuset_mem_spread_node() routine is also simple. It uses the
375
value of a per-task rotor cpuset_mem_spread_rotor to select the next
376
node in the current task's mems_allowed to prefer for the allocation.
378
This memory placement policy is also known (in other contexts) as
379
round-robin or interleave.
381
This policy can provide substantial improvements for jobs that need
382
to place thread local data on the corresponding node, but that need
383
to access large file system data sets that need to be spread across
384
the several nodes in the jobs cpuset in order to fit. Without this
385
policy, especially for jobs that might have one thread reading in the
386
data set, the memory allocation across the nodes in the jobs cpuset
387
can become very uneven.
389
1.7 What is sched_load_balance ?
390
--------------------------------
392
The kernel scheduler (kernel/sched/core.c) automatically load balances
393
tasks. If one CPU is underutilized, kernel code running on that
394
CPU will look for tasks on other more overloaded CPUs and move those
395
tasks to itself, within the constraints of such placement mechanisms
396
as cpusets and sched_setaffinity.
398
The algorithmic cost of load balancing and its impact on key shared
399
kernel data structures such as the task list increases more than
400
linearly with the number of CPUs being balanced. So the scheduler
401
has support to partition the systems CPUs into a number of sched
402
domains such that it only load balances within each sched domain.
403
Each sched domain covers some subset of the CPUs in the system;
404
no two sched domains overlap; some CPUs might not be in any sched
405
domain and hence won't be load balanced.
407
Put simply, it costs less to balance between two smaller sched domains
408
than one big one, but doing so means that overloads in one of the
409
two domains won't be load balanced to the other one.
411
By default, there is one sched domain covering all CPUs, including those
412
marked isolated using the kernel boot time "isolcpus=" argument. However,
413
the isolated CPUs will not participate in load balancing, and will not
414
have tasks running on them unless explicitly assigned.
416
This default load balancing across all CPUs is not well suited for
417
the following two situations:
419
1) On large systems, load balancing across many CPUs is expensive.
420
If the system is managed using cpusets to place independent jobs
421
on separate sets of CPUs, full load balancing is unnecessary.
422
2) Systems supporting realtime on some CPUs need to minimize
423
system overhead on those CPUs, including avoiding task load
424
balancing if that is not needed.
426
When the per-cpuset flag "cpuset.sched_load_balance" is enabled (the default
427
setting), it requests that all the CPUs in that cpusets allowed 'cpuset.cpus'
428
be contained in a single sched domain, ensuring that load balancing
429
can move a task (not otherwised pinned, as by sched_setaffinity)
430
from any CPU in that cpuset to any other.
432
When the per-cpuset flag "cpuset.sched_load_balance" is disabled, then the
433
scheduler will avoid load balancing across the CPUs in that cpuset,
434
--except-- in so far as is necessary because some overlapping cpuset
435
has "sched_load_balance" enabled.
437
So, for example, if the top cpuset has the flag "cpuset.sched_load_balance"
438
enabled, then the scheduler will have one sched domain covering all
439
CPUs, and the setting of the "cpuset.sched_load_balance" flag in any other
440
cpusets won't matter, as we're already fully load balancing.
442
Therefore in the above two situations, the top cpuset flag
443
"cpuset.sched_load_balance" should be disabled, and only some of the smaller,
444
child cpusets have this flag enabled.
446
When doing this, you don't usually want to leave any unpinned tasks in
447
the top cpuset that might use non-trivial amounts of CPU, as such tasks
448
may be artificially constrained to some subset of CPUs, depending on
449
the particulars of this flag setting in descendant cpusets. Even if
450
such a task could use spare CPU cycles in some other CPUs, the kernel
451
scheduler might not consider the possibility of load balancing that
452
task to that underused CPU.
454
Of course, tasks pinned to a particular CPU can be left in a cpuset
455
that disables "cpuset.sched_load_balance" as those tasks aren't going anywhere
456
else anyway.
458
There is an impedance mismatch here, between cpusets and sched domains.
459
Cpusets are hierarchical and nest. Sched domains are flat; they don't
460
overlap and each CPU is in at most one sched domain.
462
It is necessary for sched domains to be flat because load balancing
463
across partially overlapping sets of CPUs would risk unstable dynamics
464
that would be beyond our understanding. So if each of two partially
465
overlapping cpusets enables the flag 'cpuset.sched_load_balance', then we
466
form a single sched domain that is a superset of both. We won't move
467
a task to a CPU outside its cpuset, but the scheduler load balancing
468
code might waste some compute cycles considering that possibility.
470
This mismatch is why there is not a simple one-to-one relation
471
between which cpusets have the flag "cpuset.sched_load_balance" enabled,
472
and the sched domain configuration. If a cpuset enables the flag, it
473
will get balancing across all its CPUs, but if it disables the flag,
474
it will only be assured of no load balancing if no other overlapping
475
cpuset enables the flag.
477
If two cpusets have partially overlapping 'cpuset.cpus' allowed, and only
478
one of them has this flag enabled, then the other may find its
479
tasks only partially load balanced, just on the overlapping CPUs.
480
This is just the general case of the top_cpuset example given a few
481
paragraphs above. In the general case, as in the top cpuset case,
482
don't leave tasks that might use non-trivial amounts of CPU in
483
such partially load balanced cpusets, as they may be artificially
484
constrained to some subset of the CPUs allowed to them, for lack of
485
load balancing to the other CPUs.
487
CPUs in "cpuset.isolcpus" were excluded from load balancing by the
488
isolcpus= kernel boot option, and will never be load balanced regardless
489
of the value of "cpuset.sched_load_balance" in any cpuset.
491
1.7.1 sched_load_balance implementation details.
492
------------------------------------------------
494
The per-cpuset flag 'cpuset.sched_load_balance' defaults to enabled (contrary
495
to most cpuset flags.) When enabled for a cpuset, the kernel will
496
ensure that it can load balance across all the CPUs in that cpuset
497
(makes sure that all the CPUs in the cpus_allowed of that cpuset are
498
in the same sched domain.)
500
If two overlapping cpusets both have 'cpuset.sched_load_balance' enabled,
501
then they will be (must be) both in the same sched domain.
503
If, as is the default, the top cpuset has 'cpuset.sched_load_balance' enabled,
504
then by the above that means there is a single sched domain covering
505
the whole system, regardless of any other cpuset settings.
507
The kernel commits to user space that it will avoid load balancing
508
where it can. It will pick as fine a granularity partition of sched
509
domains as it can while still providing load balancing for any set
510
of CPUs allowed to a cpuset having 'cpuset.sched_load_balance' enabled.
512
The internal kernel cpuset to scheduler interface passes from the
513
cpuset code to the scheduler code a partition of the load balanced
514
CPUs in the system. This partition is a set of subsets (represented
515
as an array of struct cpumask) of CPUs, pairwise disjoint, that cover
516
all the CPUs that must be load balanced.
518
The cpuset code builds a new such partition and passes it to the
519
scheduler sched domain setup code, to have the sched domains rebuilt
520
as necessary, whenever:
522
- the 'cpuset.sched_load_balance' flag of a cpuset with non-empty CPUs changes,
523
- or CPUs come or go from a cpuset with this flag enabled,
524
- or 'cpuset.sched_relax_domain_level' value of a cpuset with non-empty CPUs
525
and with this flag enabled changes,
526
- or a cpuset with non-empty CPUs and with this flag enabled is removed,
527
- or a cpu is offlined/onlined.
529
This partition exactly defines what sched domains the scheduler should
530
setup - one sched domain for each element (struct cpumask) in the
531
partition.
533
The scheduler remembers the currently active sched domain partitions.
534
When the scheduler routine partition_sched_domains() is invoked from
535
the cpuset code to update these sched domains, it compares the new
536
partition requested with the current, and updates its sched domains,
537
removing the old and adding the new, for each change.
540
1.8 What is sched_relax_domain_level ?
541
--------------------------------------
543
In sched domain, the scheduler migrates tasks in 2 ways; periodic load
544
balance on tick, and at time of some schedule events.
546
When a task is woken up, scheduler try to move the task on idle CPU.
547
For example, if a task A running on CPU X activates another task B
548
on the same CPU X, and if CPU Y is X's sibling and performing idle,
549
then scheduler migrate task B to CPU Y so that task B can start on
550
CPU Y without waiting task A on CPU X.
552
And if a CPU run out of tasks in its runqueue, the CPU try to pull
553
extra tasks from other busy CPUs to help them before it is going to
554
be idle.
556
Of course it takes some searching cost to find movable tasks and/or
557
idle CPUs, the scheduler might not search all CPUs in the domain
558
every time. In fact, in some architectures, the searching ranges on
559
events are limited in the same socket or node where the CPU locates,
560
while the load balance on tick searches all.
562
For example, assume CPU Z is relatively far from CPU X. Even if CPU Z
563
is idle while CPU X and the siblings are busy, scheduler can't migrate
564
woken task B from X to Z since it is out of its searching range.
565
As the result, task B on CPU X need to wait task A or wait load balance
566
on the next tick. For some applications in special situation, waiting
567
1 tick may be too long.
569
The 'cpuset.sched_relax_domain_level' file allows you to request changing
570
this searching range as you like. This file takes int value which
571
indicates size of searching range in levels approximately as follows,
572
otherwise initial value -1 that indicates the cpuset has no request.
574
====== ===========================================================
575
-1 no request. use system default or follow request of others.
576
0 no search.
577
1 search siblings (hyperthreads in a core).
578
2 search cores in a package.
579
3 search cpus in a node [= system wide on non-NUMA system]
580
4 search nodes in a chunk of node [on NUMA system]
581
5 search system wide [on NUMA system]
582
====== ===========================================================
584
Not all levels can be present and values can change depending on the
585
system architecture and kernel configuration. Check
586
/sys/kernel/debug/sched/domains/cpu*/domain*/ for system-specific
587
details.
589
The system default is architecture dependent. The system default
590
can be changed using the relax_domain_level= boot parameter.
592
This file is per-cpuset and affect the sched domain where the cpuset
593
belongs to. Therefore if the flag 'cpuset.sched_load_balance' of a cpuset
594
is disabled, then 'cpuset.sched_relax_domain_level' have no effect since
595
there is no sched domain belonging the cpuset.
597
If multiple cpusets are overlapping and hence they form a single sched
598
domain, the largest value among those is used. Be careful, if one
599
requests 0 and others are -1 then 0 is used.
601
Note that modifying this file will have both good and bad effects,
602
and whether it is acceptable or not depends on your situation.
603
Don't modify this file if you are not sure.
605
If your situation is:
607
- The migration costs between each cpu can be assumed considerably
608
small(for you) due to your special application's behavior or
609
special hardware support for CPU cache etc.
610
- The searching cost doesn't have impact(for you) or you can make
611
the searching cost enough small by managing cpuset to compact etc.
612
- The latency is required even it sacrifices cache hit rate etc.
613
then increasing 'sched_relax_domain_level' would benefit you.
616
1.9 How do I use cpusets ?
617
--------------------------
619
In order to minimize the impact of cpusets on critical kernel
620
code, such as the scheduler, and due to the fact that the kernel
621
does not support one task updating the memory placement of another
622
task directly, the impact on a task of changing its cpuset CPU
623
or Memory Node placement, or of changing to which cpuset a task
624
is attached, is subtle.
626
If a cpuset has its Memory Nodes modified, then for each task attached
627
to that cpuset, the next time that the kernel attempts to allocate
628
a page of memory for that task, the kernel will notice the change
629
in the task's cpuset, and update its per-task memory placement to
630
remain within the new cpusets memory placement. If the task was using
631
mempolicy MPOL_BIND, and the nodes to which it was bound overlap with
632
its new cpuset, then the task will continue to use whatever subset
633
of MPOL_BIND nodes are still allowed in the new cpuset. If the task
634
was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed
635
in the new cpuset, then the task will be essentially treated as if it
636
was MPOL_BIND bound to the new cpuset (even though its NUMA placement,
637
as queried by get_mempolicy(), doesn't change). If a task is moved
638
from one cpuset to another, then the kernel will adjust the task's
639
memory placement, as above, the next time that the kernel attempts
640
to allocate a page of memory for that task.
642
If a cpuset has its 'cpuset.cpus' modified, then each task in that cpuset
643
will have its allowed CPU placement changed immediately. Similarly,
644
if a task's pid is written to another cpuset's 'tasks' file, then its
645
allowed CPU placement is changed immediately. If such a task had been
646
bound to some subset of its cpuset using the sched_setaffinity() call,
647
the task will be allowed to run on any CPU allowed in its new cpuset,
648
negating the effect of the prior sched_setaffinity() call.
650
In summary, the memory placement of a task whose cpuset is changed is
651
updated by the kernel, on the next allocation of a page for that task,
652
and the processor placement is updated immediately.
654
Normally, once a page is allocated (given a physical page
655
of main memory) then that page stays on whatever node it
656
was allocated, so long as it remains allocated, even if the
657
cpusets memory placement policy 'cpuset.mems' subsequently changes.
658
If the cpuset flag file 'cpuset.memory_migrate' is set true, then when
659
tasks are attached to that cpuset, any pages that task had
660
allocated to it on nodes in its previous cpuset are migrated
661
to the task's new cpuset. The relative placement of the page within
662
the cpuset is preserved during these migration operations if possible.
663
For example if the page was on the second valid node of the prior cpuset
664
then the page will be placed on the second valid node of the new cpuset.
666
Also if 'cpuset.memory_migrate' is set true, then if that cpuset's
667
'cpuset.mems' file is modified, pages allocated to tasks in that
668
cpuset, that were on nodes in the previous setting of 'cpuset.mems',
669
will be moved to nodes in the new setting of 'mems.'
670
Pages that were not in the task's prior cpuset, or in the cpuset's
671
prior 'cpuset.mems' setting, will not be moved.
673
There is an exception to the above. If hotplug functionality is used
674
to remove all the CPUs that are currently assigned to a cpuset,
675
then all the tasks in that cpuset will be moved to the nearest ancestor
676
with non-empty cpus. But the moving of some (or all) tasks might fail if
677
cpuset is bound with another cgroup subsystem which has some restrictions
678
on task attaching. In this failing case, those tasks will stay
679
in the original cpuset, and the kernel will automatically update
680
their cpus_allowed to allow all online CPUs. When memory hotplug
681
functionality for removing Memory Nodes is available, a similar exception
682
is expected to apply there as well. In general, the kernel prefers to
683
violate cpuset placement, over starving a task that has had all
684
its allowed CPUs or Memory Nodes taken offline.
686
There is a second exception to the above. GFP_ATOMIC requests are
687
kernel internal allocations that must be satisfied, immediately.
688
The kernel may drop some request, in rare cases even panic, if a
689
GFP_ATOMIC alloc fails. If the request cannot be satisfied within
690
the current task's cpuset, then we relax the cpuset, and look for
691
memory anywhere we can find it. It's better to violate the cpuset
692
than stress the kernel.
694
To start a new job that is to be contained within a cpuset, the steps are:
696
1) mkdir /sys/fs/cgroup/cpuset
697
2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
698
3) Create the new cpuset by doing mkdir's and write's (or echo's) in
699
the /sys/fs/cgroup/cpuset virtual file system.
700
4) Start a task that will be the "founding father" of the new job.
701
5) Attach that task to the new cpuset by writing its pid to the
702
/sys/fs/cgroup/cpuset tasks file for that cpuset.
703
6) fork, exec or clone the job tasks from this founding father task.
705
For example, the following sequence of commands will setup a cpuset
706
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
707
and then start a subshell 'sh' in that cpuset::
709
mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
710
cd /sys/fs/cgroup/cpuset
711
mkdir Charlie
712
cd Charlie
713
/bin/echo 2-3 > cpuset.cpus
714
/bin/echo 1 > cpuset.mems
715
/bin/echo $$ > tasks
716
sh
717
# The subshell 'sh' is now running in cpuset Charlie
718
# The next line should display '/Charlie'
719
cat /proc/self/cpuset
721
There are ways to query or modify cpusets:
723
- via the cpuset file system directly, using the various cd, mkdir, echo,
724
cat, rmdir commands from the shell, or their equivalent from C.
725
- via the C library libcpuset.
726
- via the C library libcgroup.
727
(https://github.com/libcgroup/libcgroup/)
728
- via the python application cset.
729
(http://code.google.com/p/cpuset/)
731
The sched_setaffinity calls can also be done at the shell prompt using
732
SGI's runon or Robert Love's taskset. The mbind and set_mempolicy
733
calls can be done at the shell prompt using the numactl command
734
(part of Andi Kleen's numa package).
736
2. Usage Examples and Syntax
737
============================
739
2.1 Basic Usage
740
---------------
742
Creating, modifying, using the cpusets can be done through the cpuset
743
virtual filesystem.
745
To mount it, type:
746
# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset
748
Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the
749
tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset
750
is the cpuset that holds the whole system.
752
If you want to create a new cpuset under /sys/fs/cgroup/cpuset::
754
# cd /sys/fs/cgroup/cpuset
755
# mkdir my_cpuset
757
Now you want to do something with this cpuset::
759
# cd my_cpuset
761
In this directory you can find several files::
763
# ls
764
cgroup.clone_children cpuset.memory_pressure
765
cgroup.event_control cpuset.memory_spread_page
766
cgroup.procs cpuset.memory_spread_slab
767
cpuset.cpu_exclusive cpuset.mems
768
cpuset.cpus cpuset.sched_load_balance
769
cpuset.mem_exclusive cpuset.sched_relax_domain_level
770
cpuset.mem_hardwall notify_on_release
771
cpuset.memory_migrate tasks
773
Reading them will give you information about the state of this cpuset:
774
the CPUs and Memory Nodes it can use, the processes that are using
775
it, its properties. By writing to these files you can manipulate
776
the cpuset.
778
Set some flags::
780
# /bin/echo 1 > cpuset.cpu_exclusive
782
Add some cpus::
784
# /bin/echo 0-7 > cpuset.cpus
786
Add some mems::
788
# /bin/echo 0-7 > cpuset.mems
790
Now attach your shell to this cpuset::
792
# /bin/echo $$ > tasks
794
You can also create cpusets inside your cpuset by using mkdir in this
795
directory::
797
# mkdir my_sub_cs
799
To remove a cpuset, just use rmdir::
801
# rmdir my_sub_cs
803
This will fail if the cpuset is in use (has cpusets inside, or has
804
processes attached).
806
Note that for legacy reasons, the "cpuset" filesystem exists as a
807
wrapper around the cgroup filesystem.
809
The command::
811
mount -t cpuset X /sys/fs/cgroup/cpuset
813
is equivalent to::
815
mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset
816
echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent
818
2.2 Adding/removing cpus
819
------------------------
821
This is the syntax to use when writing in the cpus or mems files
822
in cpuset directories::
824
# /bin/echo 1-4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
825
# /bin/echo 1,2,3,4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
827
To add a CPU to a cpuset, write the new list of CPUs including the
828
CPU to be added. To add 6 to the above cpuset::
830
# /bin/echo 1-4,6 > cpuset.cpus -> set cpus list to cpus 1,2,3,4,6
832
Similarly to remove a CPU from a cpuset, write the new list of CPUs
833
without the CPU to be removed.
835
To remove all the CPUs::
837
# /bin/echo "" > cpuset.cpus -> clear cpus list
839
2.3 Setting flags
840
-----------------
842
The syntax is very simple::
844
# /bin/echo 1 > cpuset.cpu_exclusive -> set flag 'cpuset.cpu_exclusive'
845
# /bin/echo 0 > cpuset.cpu_exclusive -> unset flag 'cpuset.cpu_exclusive'
847
2.4 Attaching processes
848
-----------------------
850
::
852
# /bin/echo PID > tasks
854
Note that it is PID, not PIDs. You can only attach ONE task at a time.
855
If you have several tasks to attach, you have to do it one after another::
857
# /bin/echo PID1 > tasks
858
# /bin/echo PID2 > tasks
859
...
860
# /bin/echo PIDn > tasks
863
3. Questions
864
============
866
Q:
867
what's up with this '/bin/echo' ?
869
A:
870
bash's builtin 'echo' command does not check calls to write() against
871
errors. If you use it in the cpuset file system, you won't be
872
able to tell whether a command succeeded or failed.
874
Q:
875
When I attach processes, only the first of the line gets really attached !
877
A:
878
We can only return one error code per call to write(). So you should also
879
put only ONE pid.
881
4. Contact
882
==========
884
Web: http://www.bullopensource.org/cpuset
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서 범위와 구성
1-39이 문서는 BULL SA와 Silicon Graphics의 copyright 아래 `[email protected]`가 작성했으며 Paul Jackson `<[email protected]>`, Christoph Lameter `<[email protected]>`, Paul Menage `<[email protected]>`, Hidetoshi Seto `<[email protected]>`가 수정했습니다.
본문은 cpuset의 정의·필요성·구현, exclusive·memory pressure·memory spread, scheduler load balancing과 relax level, 실제 사용법, syntax 예제와 FAQ를 차례로 설명합니다.
PartCoverage
1. CpusetsModel, implementation, memory and scheduler controls
2. Usage Examples and SyntaxMount, files, masks, flags, task attachment
3. Questions/bin/echo와 one-PID write 규칙
4. ContactOriginal project contact
원문의 네 부분과 핵심 주제입니다.
Cpuset 정의와 placement filtering
40-71Cpuset은 task 집합에 CPU 집합과 Memory Node 집합을 할당하는 mechanism입니다. 여기서 Memory Node는 memory를 포함하는 online node를 뜻합니다. 각 task의 CPU·memory placement는 현재 cpuset 안의 resource로 제한되며, cpuset은 virtual filesystem에 보이는 nested hierarchy를 이룹니다.
이 mechanism은 대형 system의 dynamic job placement를 관리하는 데 필요한 최소 hook을 제공합니다. Generic cgroup subsystem 자체는 `Documentation/admin-guide/cgroup-v1/cgroups.rst`에서 설명합니다.
Request or stateCpuset filterKernel enforcement
sched_setaffinity(2) CPU mask현재 cpuset 밖의 CPU 제거Scheduler uses task cpus_allowed
mbind(2) / set_mempolicy(2) node mask현재 cpuset 밖의 Memory Node 제거Page allocator uses task mems_allowed
User request와 kernel enforcement가 만나는 지점입니다.
Requested CPU affinity→Intersect with cpuset.cpus→cpus_allowed→Scheduler placement
Requested NUMA policy→Intersect with cpuset.mems→mems_allowed→Page allocation
Task가 요청한 mask는 cpuset mask와 교집합을 취합니다.
User-space는 cgroup virtual filesystem에서 cpuset을 name으로 생성·삭제하고 permission과 attribute, CPU·Memory Node assignment를 관리합니다. 또한 task가 속한 cpuset을 지정·조회하고 cpuset별 PID를 열거할 수 있습니다.
대형 NUMA system에서 cpuset이 필요한 이유
72-109CPU가 많고 cache hierarchy가 복잡하며 access time이 균일하지 않은 여러 Memory Node를 가진 NUMA system에서는 process scheduling과 memory placement가 더 어렵습니다. 작은 system은 OS가 자동으로 CPU·memory를 공유해도 충분하지만, 큰 system은 memory access time과 contention을 줄이도록 job을 적절한 system subset에 명시적으로 배치하는 편이 유리합니다.
SystemWhy placement matters
Multiple web application instancesInstance별 CPU·memory 격리와 sizing
Mixed application serverWeb server와 database 간 contention 제어
Large NUMA HPC workloadLocality와 예측 가능한 performance 유지
명시적 soft partition이 특히 유용한 workload입니다.
이 subset, 즉 soft partition은 job mix가 바뀔 때 concurrent job에 영향을 주지 않고 dynamic하게 조정할 수 있어야 합니다. Memory location이 바뀌면 실행 중인 job의 page 위치도 옮길 수 있어야 합니다.
Changing job mix→Resize CPU and Memory Node subset→Optionally migrate job pages→Other jobs remain isolated
Cpuset은 existing Linux placement facility 위에서 job resource를 조정합니다.
Kernel cpuset patch는 이런 subset을 효율적으로 구현하는 데 필요한 최소 mechanism만 제공합니다. 기존 CPU·memory placement facility를 재사용하므로 scheduler와 memory allocator의 critical path에 추가 영향을 피합니다.
Kernel 구현, filesystem 파일과 계층 규칙
110-239Linux에는 이미 `sched_setaffinity`로 CPU를, `mbind`와 `set_mempolicy`로 Memory Node를 정하는 mechanism이 있습니다. Cpuset은 kernel이 아는 allowed CPU·node set을 만들고, 모든 task를 reference-counted cgroup structure를 가리키는 task-structure pointer로 한 cpuset에 연결합니다.
Location or operationCpuset responsibility
init/main.cBoot 때 root cpuset 초기화
fork / exitTask의 cpuset attach·detach
sched_setaffinityRequested CPU mask를 cpuset mask로 제한
sched.c migrate_live_tasks()가능하면 allowed CPU 안에서 task migration
mbind / set_mempolicyRequested node mask를 cpuset mask로 제한
page_alloc.cAllowed node로 allocation 제한
vmscan.cCurrent cpuset 안에서 page recovery 제한
Performance critical path를 피하면서 placement를 강제하는 주요 hook입니다.
Root cpuset은 system의 모든 CPU와 Memory Node를 포함합니다. Child는 parent resource의 subset만 가질 수 있고 `/dev/cpuset`에 hierarchy를 mount해 user-space에서 조작할 수 있습니다. `cpu_exclusive` 또는 `mem_exclusive`를 설정하면 direct ancestor·descendant를 제외한 다른 cpuset과 해당 resource가 겹치지 않도록 보장합니다.
Cpuset을 위해 새 system call은 추가되지 않습니다. `cgroup` filesystem을 mount하고 directory와 file을 읽고 쓰는 방식으로 kernel에 알려진 cpuset을 조회·수정합니다.
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list: 0-127
Mems_allowed: ffffffff,ffffffff
Mems_allowed_list: 0-63각 task의 `/proc/<pid>/status`에는 `Cpus_allowed`, `Cpus_allowed_list`, `Mems_allowed`, `Mems_allowed_list`가 추가되어 허용된 CPU와 Memory Node를 bitmap과 list 형식으로 보여 줍니다.
FilePurpose
cpuset.cpusAllowed CPU list
cpuset.memsAllowed Memory Node list
cpuset.memory_migrateAttach 또는 mems 변경 시 page migration
cpuset.cpu_exclusiveCPU placement exclusivity
cpuset.mem_exclusiveMemory placement exclusivity
cpuset.mem_hardwallKernel memory allocation hardwall
cpuset.memory_pressureDirect-reclaim pressure metric
cpuset.memory_spread_pagePage cache를 allowed node에 분산
cpuset.memory_spread_slabObsolete; no function
cpuset.sched_load_balanceCpuset CPU 안의 load balancing 요청
cpuset.sched_relax_domain_levelEvent migration search range
cpuset.memory_pressure_enabledRoot only; pressure 계산 활성화
Standard cgroup file 외에 cpuset controller가 제공하는 핵심 interface입니다.
`mkdir`로 새 cpuset을 만들고 directory 안의 file에 write해 flag, allowed CPU·node와 attached task를 바꿉니다. Child는 fork 때 parent task의 cpuset attachment를 자동 상속하며 permission이 허용하면 다른 cpuset으로 re-attach할 수 있습니다.
각 cpuset의 CPU와 Memory Node는 parent의 subset이어야 하고, parent가 exclusive가 아니면 child도 exclusive가 될 수 없습니다. CPU 또는 memory가 exclusive이면 sibling과 겹칠 수 없습니다. Hierarchy 덕분에 모든 cpuset을 매번 scan하지 않고 이 보장을 효율적으로 검사합니다.
top_cpuset read-only cpus/mems→Tracks cpu_online_mask and node_states[N_MEMORY]→Child cpuset requests subset→Effective task placement
cpuset_v2_mode mount→Hotplug leaves cpuset.cpus/mems unchanged→cpuset.effective_cpus/effective_mems show actual resources
Top cpuset과 child resource, hotplug 관측의 관계입니다.
Root `cpuset.cpus`와 `cpuset.mems`는 read-only입니다. CPU hotplug notifier가 `cpu_online_mask`를, `cpuset_track_online_nodes()` hook이 memory가 있는 `node_states[N_MEMORY]`를 자동 추적합니다. 보통 `cpuset.effective_cpus`와 `cpuset.effective_mems`는 configured file의 read-only copy입니다.
`cpuset_v2_mode` mount option을 쓰면 hotplug가 `cpuset.cpus`와 `cpuset.mems`를 바꾸지 않고 effective file만 현재 실제 resource를 반영합니다. 자세한 v2 동작은 `Documentation/admin-guide/cgroup-v2.rst`를 참고합니다.
Exclusive cpuset과 hardwall
240-260CPU 또는 memory exclusive cpuset은 direct ancestor·descendant를 제외한 다른 cpuset과 같은 CPU나 Memory Node를 공유할 수 없습니다.
`cpuset.mem_exclusive` 또는 `cpuset.mem_hardwall`이 설정된 cpuset은 hardwalled입니다. User-space memory는 모든 cpuset에서 제한하지만, hardwall은 page·buffer와 여러 user가 공유하는 kernel data allocation까지 제한합니다.
ConfigurationUser allocationShared kernel allocation
Ordinary cpusetRestricted to cpusetMay be shared across cpusets
mem_exclusive or mem_hardwallRestricted to cpusetNormally restricted to hardwall
Interrupt-handler and exceptional kernel requestNot applicableSmall amount may escape even mem_exclusive
일반 cpuset과 hardwalled cpuset의 allocation 차이입니다.
Large mem_exclusive parent→Shared kernel data such as filesystem pages→Non-mem_exclusive child per job→Each job user memory remains isolated
여러 job이 filesystem page를 공유하면서 user allocation을 격리하는 구성입니다.
memory_pressure metric
261-318Cpuset의 `memory_pressure`는 그 cpuset task가 추가 memory request를 만족하려고 allowed node의 사용 중 memory를 free하려 시도하는 rate를 나타내는 간단한 per-cpuset metric입니다. Batch manager는 dedicated cpuset에서 job이 일으키는 memory pressure를 효율적으로 감지할 수 있습니다.
허용된 memory를 넘겨 쓰려는 job을 종료·reprioritize해야 하는 managed system과, paging이 시작되면 performance goal을 크게 놓치는 tightly coupled long-running scientific workload 모두에 유용합니다. Metric은 pressure를 알려 줄 뿐이며 실제 대응은 batch manager나 user code가 결정합니다.
Write 1 to /dev/cpuset/memory_pressure_enabled→cpuset_memory_pressure_enabled becomes nonzero→Task enters synchronous direct reclaim in __alloc_pages()→Per-cpuset filter updates→Read cpuset.memory_pressure
Feature disabled→Rebalance hook only observes zero flag→No metric computation cost
Feature를 켠 system에서만 direct reclaim hook이 metric을 갱신합니다.
이 meter는 per-task나 per-mm가 아니라 per-cpuset이므로 query마다 tasklist를 scan할 필요가 없습니다. 누적 counter가 아니라 running average이므로 scheduler는 시간 간격을 두고 여러 값을 읽어 직접 누적하지 않고도 한 번의 read로 최근 pressure를 판단할 수 있습니다.
PropertyValue
State costSpinlock and three words per cpuset
Update sourceAny attached task entering synchronous direct reclaim
FilterSimple digital running-average filter
Half-life10 seconds
Reported unitDirect reclaim attempts per second multiplied by 1000
작은 비용으로 최근 direct reclaim rate를 표현합니다.
Page cache와 slab memory spread
319-388`cpuset.memory_spread_page`와 `cpuset.memory_spread_slab`은 filesystem buffer와 관련 kernel data page를 어디에 allocate할지 제어하는 boolean flag입니다. Page flag는 page cache를 task가 사용할 수 있는 모든 node에 고르게 분산합니다. Slab flag는 inode·dentry 같은 일부 filesystem-related slab cache를 분산하지만 현재 interface 목록에서는 obsolete이며 기능이 없습니다.
Flag or allocationEffect
cpuset.memory_spread_pagePage cache를 allowed nodes에 균등 분산
cpuset.memory_spread_slabHistorically selected slab caches; now obsolete
Anonymous data and stack pagesSpread flag의 영향을 받지 않음
Default value0; local-node allocation preferred
New child cpusetParent memory-spread setting 상속
영향을 받는 allocation과 받지 않는 allocation입니다.
기본적으로 spread는 꺼져 있고 free memory가 충분하면 task가 실행 중인 local node에서 page를 allocate합니다. Task NUMA mempolicy 또는 cpuset configuration이 이를 제한할 수 있습니다. Spread를 켜면 대상 page/slab cache는 task의 NUMA mempolicy를 무시하고 분산되며, 끄면 현재 NUMA mempolicy가 다시 적용됩니다. `mbind()`나 `set_mempolicy()` 호출 자체의 보이는 결과는 바뀌지 않습니다.
`cpuset.memory_spread_page`를 켜면 cpuset에 있거나 이후 들어오는 각 task에 `PFA_SPREAD_PAGE`가 설정됩니다. Page-cache allocation이 이 flag를 확인하고 `cpuset_mem_spread_node()`가 preferred node를 반환합니다. Historical slab spread는 `PFA_SPREAD_SLAB`과 같은 routine을 사용합니다.
Allocation checks PFA_SPREAD_PAGE or PFA_SPREAD_SLAB→cpuset_mem_spread_node()→Read task cpuset_mem_spread_rotor→Select next node in mems_allowed→Advance rotor
`cpuset_mem_spread_rotor`가 allowed node를 순환 선택합니다.
이 정책은 round-robin 또는 interleave로도 불립니다. Thread-local data는 해당 node에 두되 한 thread가 읽는 대형 filesystem dataset을 job cpuset의 여러 node에 고르게 펼쳐야 할 때 allocation 쏠림을 줄여 큰 성능 향상을 낼 수 있습니다.
sched_load_balance와 flat sched domain
389-490Kernel scheduler(`kernel/sched/core.c`)는 underutilized CPU가 더 바쁜 CPU에서 movable task를 가져오는 방식으로 자동 load balancing합니다. 하지만 balancing 비용과 task list 같은 shared kernel structure에 미치는 영향은 CPU 수보다 더 빠르게 증가합니다.
Scheduler는 CPU를 겹치지 않는 flat sched domain으로 partition해 domain 안에서만 balance할 수 있습니다. 작은 domain 둘은 큰 domain 하나보다 싸지만 한 domain의 overload를 다른 domain으로 옮기지 못합니다. 어떤 CPU는 domain에 속하지 않아 balance되지 않을 수도 있습니다.
ScenarioProblem with one global domainPreferred setup
Independent jobs on a large system많은 CPU를 매번 탐색하는 비용Job cpuset별 smaller domain
Realtime workloadUnneeded balancing overhead and latencyDisable balancing on dedicated CPUs
대형 system과 realtime CPU에서 전체-system balancing을 피하는 이유입니다.
기본적으로 `isolcpus=`로 표시한 CPU까지 포함하는 하나의 sched domain이 있지만 isolated CPU는 load balancing에 참여하지 않고 명시적으로 assign하지 않으면 task가 실행되지 않습니다.
Per-cpuset `cpuset.sched_load_balance`가 켜지면 해당 `cpuset.cpus`의 모든 CPU를 한 sched domain 안에 두도록 요청합니다. `sched_setaffinity`로 별도 pin되지 않은 task는 그 cpuset CPU 사이에서 이동할 수 있습니다. Flag를 끄면 overlapping cpuset이 balancing을 요구하는 데 필요한 범위를 제외하고 그 CPU 사이의 balance를 피합니다.
Cpuset A enables sched_load_balance→Cpuset B partially overlaps and enables it→Build one sched domain covering superset A union B→Task placement still obeys each task cpuset
Top cpuset enables balancing→One domain covers all CPUs→Descendant flag values cannot reduce it
Cpuset hierarchy와 flat sched domain 사이의 impedance mismatch입니다.
따라서 independent job이나 realtime CPU 구성을 만들 때는 top cpuset의 `cpuset.sched_load_balance`를 끄고 필요한 smaller child에서만 켜는 것이 일반적입니다. Top 또는 partially balanced cpuset에 상당한 CPU를 쓰는 unpinned task를 남기면 spare CPU가 있어도 scheduler가 그 이동을 고려하지 않아 일부 CPU subset에 갇힐 수 있습니다.
Cpuset은 hierarchical하고 겹칠 수 있지만 sched domain은 flat하고 서로 겹치지 않습니다. Partially overlapping balancing cpuset은 모두 포함하는 하나의 superset domain으로 합칩니다. Scheduler가 cpuset 밖 CPU로 task를 실제 이동시키지는 않지만 그 가능성을 검토하는 계산은 낭비될 수 있습니다.
ConditionResult
No overlapping enabled cpusetDisabled cpuset의 CPU 사이 balancing 회피
Overlapping enabled cpusetOverlap 범위에서는 partial balancing 가능
Top cpuset enabledSystem-wide sched domain
CPU listed in cpuset.isolcpus by isolcpus=Any cpuset flag와 무관하게 never load balanced
Flag를 껐다고 항상 balancing이 사라지는 것은 아닙니다.
Sched-domain partition 재구성
491-539`cpuset.sched_load_balance`는 대부분의 cpuset flag와 달리 기본값이 enabled입니다. Enabled cpuset의 `cpus_allowed` 전체가 같은 sched domain에 들어가도록 보장하며, 서로 겹치는 enabled cpuset은 같은 domain에 있어야 합니다.
Kernel은 balancing requirement를 만족하면서 가능한 한 fine-grained한 sched-domain partition을 선택해 불필요한 balancing을 피하겠다고 user-space에 약속합니다. Cpuset code는 load-balanced CPU partition을 pairwise-disjoint `struct cpumask` array로 scheduler에 전달합니다.
TriggerScope
cpuset.sched_load_balance changesCpuset has non-empty CPUs
CPU added or removedFlag-enabled cpuset
cpuset.sched_relax_domain_level changesNon-empty enabled cpuset
Cpuset removedNon-empty enabled cpuset
CPU offline or onlineSystem topology
다음 변화가 생기면 cpuset code가 새 partition을 계산합니다.
Cpuset topology or flag changes→Build disjoint struct cpumask partition→partition_sched_domains()→Compare requested and active partitions→Remove changed old domains→Add changed new domains
각 disjoint cpumask가 scheduler domain 하나를 정확히 정의합니다.
이 partition은 scheduler가 만들 domain을 정확히 정의하며 element 하나가 domain 하나에 대응합니다. Scheduler는 현재 active partition을 기억하고 `partition_sched_domains()` 호출 때 새 요청과 비교해 달라진 domain만 제거·추가합니다.
sched_relax_domain_level
540-615Sched domain에서 task migration은 tick의 periodic load balance와 wakeup 같은 scheduling event에서 일어납니다. CPU X의 task A가 task B를 깨우고 sibling CPU Y가 idle이면 scheduler는 B를 Y로 옮겨 A를 기다리지 않게 할 수 있습니다. Runqueue가 빈 CPU도 idle에 들어가기 전에 busy CPU에서 task를 가져오려 합니다.
Movable task나 idle CPU를 찾는 데 비용이 있으므로 event마다 domain 전체를 검색하지 않을 수 있습니다. Architecture에 따라 event search는 socket이나 node 안으로 제한되고 tick balance만 전체를 볼 수 있습니다. 먼 CPU Z가 idle이어도 wakeup search 범위 밖이면 B는 A 또는 다음 tick을 기다려야 합니다.
ValueRequested event-search range
-1No request; system default or other cpuset request
0No search
1Sibling hyperthreads in a core
2Cores in a package
3CPUs in a node; system-wide on non-NUMA
4Nodes in a chunk on NUMA
5System-wide on NUMA
Search range의 대략적 수준이며 실제 topology는 architecture와 configuration에 따라 다릅니다.
System-specific level은 `/sys/kernel/debug/sched/domains/cpu*/domain*/`에서 확인합니다. Default는 architecture-dependent이며 `relax_domain_level=` boot parameter로 바꿀 수 있습니다.
cpuset.sched_load_balance disabled→No sched domain for cpuset→sched_relax_domain_level has no effect
Overlapping cpusets share one domain→Collect requested levels→Use largest value
Cpuset별 요청은 실제로 속한 sched domain 단위로 결합됩니다.
Overlapping cpuset이 한 domain을 만들면 요청 중 가장 큰 값을 사용합니다. 한 곳이 0이고 다른 곳이 -1이면 0이 선택됩니다. Search 범위를 키우면 latency는 줄일 수 있지만 cache hit rate와 search cost를 희생할 수 있으므로 확신이 없으면 수정하지 않아야 합니다.
CPU 간 migration cost가 application이나 hardware 특성상 작고, compact cpuset 관리 등으로 search cost를 감당할 수 있으며, cache hit보다 latency가 중요할 때 level을 높이는 것이 이득일 수 있습니다.
Cpuset 변경 시 task placement와 page migration
616-735Kernel은 다른 task의 memory placement를 직접 update하는 mechanism을 제공하지 않고 critical code의 cpuset 영향도 줄여야 하므로 CPU와 memory 변경의 반영 시점이 다릅니다.
ChangeCPU placementMemory placement
cpuset.mems modifiedNo direct CPU effectTask의 next page allocation 때 갱신
cpuset.cpus modifiedImmediately updates each taskNo direct memory effect
PID written to another tasks fileImmediately uses new cpuset CPUsNext page allocation
Cpuset resource 또는 task attachment 변경이 적용되는 시점입니다.
Task가 `MPOL_BIND`를 쓰고 새 cpuset과 기존 bound node가 겹치면 여전히 허용된 subset을 계속 사용합니다. 겹치는 node가 하나도 없으면 `get_mempolicy()`로 보이는 NUMA policy 자체는 바뀌지 않지만 실질적으로 새 cpuset node에 bind된 것처럼 처리합니다.
`cpuset.cpus` 변경이나 task 이동은 CPU placement에 즉시 적용됩니다. Task가 과거 `sched_setaffinity()`로 cpuset의 일부 CPU에만 bind돼 있었더라도 새 cpuset으로 이동하면 이전 affinity 효과가 무효화되고 새 cpuset의 모든 allowed CPU에서 실행할 수 있습니다.
보통 이미 allocate된 physical page는 이후 `cpuset.mems`가 바뀌어도 원래 node에 남습니다. `cpuset.memory_migrate`를 켜면 task attach 시 old cpuset node의 page를 new cpuset node로 옮기며 가능하면 old/new mask 안의 상대 위치를 보존합니다. 예를 들어 old cpuset의 두 번째 valid node page는 new cpuset의 두 번째 valid node로 갑니다.
Attach task to memory_migrate cpuset→Select pages on task previous cpuset nodes→Map relative node position where possible→Move into new cpuset nodes
Modify cpuset.mems→Select task pages on previous mems→Move into new mems→Leave pages outside previous mask untouched
Task 이동과 mems 변경에서 migration 대상 page를 제한합니다.
ExceptionKernel behavior
Hotplug removes every CPU in a cpusetMove tasks to nearest ancestor with non-empty CPUs
Other controller rejects hotplug-driven attachKeep task, expand cpus_allowed to all online CPUs
Future equivalent memory-node hotplugExpected to prefer runnable task over strict placement
Unsatisfied GFP_ATOMIC allocationRelax cpuset and search memory anywhere
Task starvation이나 kernel failure를 피하려고 cpuset 제한보다 생존성을 우선합니다.
Hotplug로 cpuset의 CPU가 모두 사라지면 task를 non-empty CPU를 가진 가장 가까운 ancestor로 옮깁니다. 다른 cgroup subsystem의 attach restriction 때문에 실패하면 task는 원래 cpuset에 남고 kernel이 `cpus_allowed`를 모든 online CPU로 넓힙니다. Kernel은 task를 굶기는 것보다 cpuset placement 위반을 택합니다.
`GFP_ATOMIC`은 즉시 만족해야 하는 internal allocation입니다. 실패하면 request drop이나 드물게 panic이 날 수 있으므로 current cpuset 안에서 만족할 수 없으면 제한을 풀어 system 어디서든 memory를 찾습니다.
새 job은 cpuset filesystem을 mount하고 directory와 allowed mask를 설정한 뒤 founding-father task의 PID를 `tasks`에 쓰고 그 task에서 `fork`, `exec`, `clone`해 시작합니다.
mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
cd /sys/fs/cgroup/cpuset
mkdir Charlie
cd Charlie
/bin/echo 2-3 > cpuset.cpus
/bin/echo 1 > cpuset.mems
/bin/echo $$ > tasks
sh
# The subshell 'sh' is now running in cpuset Charlie
# The next line should display '/Charlie'
cat /proc/self/cpusetMount cpuset controller→mkdir Charlie→Write 2-3 to cpuset.cpus→Write 1 to cpuset.mems→Write $$ to tasks→Start sh→/proc/self/cpuset reports /Charlie
CPU 2-3과 Memory Node 1에서 subshell을 시작합니다.
Cpuset은 shell의 filesystem command, C library `libcpuset`, C library `libcgroup`(`https://github.com/libcgroup/libcgroup/`), Python application `cset`(`http://code.google.com/p/cpuset/`)으로 조회·수정할 수 있습니다. Shell에서는 SGI의 `runon` 또는 Robert Love의 `taskset`으로 affinity를, Andi Kleen의 numa package에 포함된 `numactl`로 `mbind`·`set_mempolicy`를 다룰 수 있습니다.
Mount, file syntax와 task attachment
736-862Cpuset 생성·수정·사용은 cpuset virtual filesystem을 통해 수행합니다. 다음 명령으로 controller를 mount하면 `/sys/fs/cgroup/cpuset` 아래의 directory tree가 system cpuset hierarchy와 대응합니다.
To mount it, type:
# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset`mkdir my_cpuset`으로 child를 만들고 그 directory에서 file을 읽어 allowed CPU·Memory Node, attached process와 property를 조회하며 write로 값을 바꿉니다.
# ls
cgroup.clone_children cpuset.memory_pressure
cgroup.event_control cpuset.memory_spread_page
cgroup.procs cpuset.memory_spread_slab
cpuset.cpu_exclusive cpuset.mems
cpuset.cpus cpuset.sched_load_balance
cpuset.mem_exclusive cpuset.sched_relax_domain_level
cpuset.mem_hardwall notify_on_release
cpuset.memory_migrate tasks
Reading them will give you information about the state of this cpuset:
the CPUs and Memory Nodes it can use, the processes that are using
it, its properties. By writing to these files you can manipulate
the cpuset.
mkdir my_cpuset→Write flags→Write cpuset.cpus→Write cpuset.mems→Write $$ to tasks→Optionally mkdir child→rmdir only when unused
Resource 설정 뒤 task를 attach하고 비어 있을 때 제거합니다.
`rmdir`는 child cpuset이나 attached process가 있으면 실패합니다. Legacy `cpuset` filesystem은 cgroup filesystem wrapper이며 다음 두 구성은 동등합니다.
The command::
mount -t cpuset X /sys/fs/cgroup/cpuset
is equivalent to::
mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset
echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agentWrapper form은 `cpuset,noprefix` mount와 `/sbin/cpuset_release_agent`를 `release_agent`에 쓰는 구성을 함께 제공합니다.
in cpuset directories::
# /bin/echo 1-4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
# /bin/echo 1,2,3,4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
To add a CPU to a cpuset, write the new list of CPUs including the
CPU to be added. To add 6 to the above cpuset::
# /bin/echo 1-4,6 > cpuset.cpus -> set cpus list to cpus 1,2,3,4,6
Similarly to remove a CPU from a cpuset, write the new list of CPUs
without the CPU to be removed.
To remove all the CPUs::
# /bin/echo "" > cpuset.cpus -> clear cpus list`cpuset.cpus`와 `cpuset.mems`에는 `1-4` 또는 `1,2,3,4`처럼 range·comma list를 씁니다. CPU를 추가·제거할 때는 delta가 아니라 새 전체 list를 다시 쓰고, 빈 문자열을 쓰면 list를 비웁니다.
TargetAccepted valueRule
cpuset.cpus / cpuset.memsRanges and comma listsWrite complete new mask
Boolean flag1 or 0Set or unset
tasksOne PID per write()Repeat writes for multiple tasks
File 유형별 write 규칙입니다.
The syntax is very simple::
# /bin/echo 1 > cpuset.cpu_exclusive -> set flag 'cpuset.cpu_exclusive'
# /bin/echo 0 > cpuset.cpu_exclusive -> unset flag 'cpuset.cpu_exclusive'
2.4 Attaching processes
-----------------------
::
# /bin/echo PID > tasks
Note that it is PID, not PIDs. You can only attach ONE task at a time.
If you have several tasks to attach, you have to do it one after another::
# /bin/echo PID1 > tasks
# /bin/echo PID2 > tasks
...
# /bin/echo PIDn > tasksTask attach는 `tasks`에 PID 하나를 쓰는 방식입니다. 한 번에 여러 task를 옮기려면 PID마다 write를 하나씩 수행해야 합니다.
FAQ와 contact
863-884QuestionAnswer
왜 /bin/echo를 쓰는가?Bash builtin echo는 write() error를 검사하지 않아 성공 여부를 알 수 없기 때문
왜 여러 PID 중 첫 task만 attach되는가?write() 호출 하나당 error code 하나만 반환하므로 PID 하나만 써야 하기 때문
Filesystem write 결과와 task attach를 신뢰하기 위한 규칙입니다.
따라서 cpuset filesystem을 shell에서 조작할 때는 `/bin/echo`를 사용하고 `tasks`에는 한 번에 PID 하나만 씁니다.
원 문서의 contact Web 주소는 `http://www.bullopensource.org/cpuset`입니다.
Model and implementation
cpusets.rst:1-260Cpuset의 placement filtering, hierarchy, filesystem interface와 exclusive hardwall을 설명합니다.