doc: cpuset: Update the cpuset flag file

This patch is for modifying with correct cuset flag file. We need to update current manual for cpuset. For example, before) cpus, cpu_exclusive, mems after ) cpuset.cpus, cpuset.cpu_exclusive, cpuset.mems Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com> Acked-by: Paul Menage <menage@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

doc: cpuset: Update the cpuset flag file
This patch is for modifying with correct cuset flag file. We need to update current manual for cpuset. For example, before) cpus, cpu_exclusive, mems after ) cpuset.cpus, cpuset.cpu_exclusive, cpuset.mems Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com> Acked-by: Paul Menage <menage@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
GeunSik Lim · Jiri Kosina
1 parent 586f64c749
Showing 1 changed file with 65 additions and 62 deletions Side-by-side Diff
Documentation/cgroups/cpusets.txt
@@ -168,20 +168,20 @@
 containing (on top of the standard cgroup files) the following
 files describing that cpuset:
  
- - cpus: list of CPUs in that cpuset
- - mems: list of Memory Nodes in that cpuset
- - memory_migrate flag: if set, move pages to cpusets nodes
- - cpu_exclusive flag: is cpu placement exclusive?
- - mem_exclusive flag: is memory placement exclusive?
- - mem_hardwall flag:  is memory allocation hardwalled
- - memory_pressure: measure of how much paging pressure in cpuset
- - memory_spread_page flag: if set, spread page cache evenly on allowed nodes
- - memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
- - sched_load_balance flag: if set, load balance within CPUs on that cpuset
- - sched_relax_domain_level: the searching range when migrating tasks
+ - cpuset.cpus: list of CPUs in that cpuset
+ - cpuset.mems: list of Memory Nodes in that cpuset
+ - cpuset.memory_migrate flag: if set, move pages to cpusets nodes
+ - cpuset.cpu_exclusive flag: is cpu placement exclusive?
+ - cpuset.mem_exclusive flag: is memory placement exclusive?
+ - cpuset.mem_hardwall flag:  is memory allocation hardwalled
+ - cpuset.memory_pressure: measure of how much paging pressure in cpuset
+ - cpuset.memory_spread_page flag: if set, spread page cache evenly on allowed nodes
+ - cpuset.memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
+ - cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset
+ - cpuset.sched_relax_domain_level: the searching range when migrating tasks
  
 In addition, the root cpuset only has the following file:
- - memory_pressure_enabled flag: compute memory_pressure?
+ - cpuset.memory_pressure_enabled flag: compute memory_pressure?
  
 New cpusets are created using the mkdir system call or shell
 command.  The properties of a cpuset, such as its flags, allowed
@@ -229,7 +229,7 @@
 a direct ancestor or descendant, may share any of the same CPUs or
 Memory Nodes.
  
-A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled",
+A cpuset that is cpuset.mem_exclusive *or* cpuset.mem_hardwall is "hardwalled",
 i.e. it restricts kernel allocations for page, buffer and other data
 commonly shared by the kernel across multiple users.  All cpusets,
 whether hardwalled or not, restrict allocations of memory for user
  
  
@@ -304,15 +304,15 @@
 ---------------------------
 There are two boolean flag files per cpuset that control where the
 kernel allocates pages for the file system buffers and related in
-kernel data structures.  They are called 'memory_spread_page' and
-'memory_spread_slab'.
+kernel data structures.  They are called 'cpuset.memory_spread_page' and
+'cpuset.memory_spread_slab'.
  
-If the per-cpuset boolean flag file 'memory_spread_page' is set, then
+If the per-cpuset boolean flag file 'cpuset.memory_spread_page' is set, then
 the kernel will spread the file system buffers (page cache) evenly
 over all the nodes that the faulting task is allowed to use, instead
 of preferring to put those pages on the node where the task is running.
  
-If the per-cpuset boolean flag file 'memory_spread_slab' is set,
+If the per-cpuset boolean flag file 'cpuset.memory_spread_slab' is set,
 then the kernel will spread some file system related slab caches,
 such as for inodes and dentries evenly over all the nodes that the
 faulting task is allowed to use, instead of preferring to put those
  
  
@@ -337,21 +337,21 @@
 is turned off, then the currently specified NUMA mempolicy once again
 applies to memory page allocations.
  
-Both 'memory_spread_page' and 'memory_spread_slab' are boolean flag
+Both 'cpuset.memory_spread_page' and 'cpuset.memory_spread_slab' are boolean flag
 files.  By default they contain "0", meaning that the feature is off
 for that cpuset.  If a "1" is written to that file, then that turns
 the named feature on.
  
 The implementation is simple.
  
-Setting the flag 'memory_spread_page' turns on a per-process flag
+Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
 PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
 joins that cpuset.  The page allocation calls for the page cache
 is modified to perform an inline check for this PF_SPREAD_PAGE task
 flag, and if set, a call to a new routine cpuset_mem_spread_node()
 returns the node to prefer for the allocation.
  
-Similarly, setting 'memory_spread_slab' turns on the flag
+Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
 PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
 pages from the node returned by cpuset_mem_spread_node().
  
  
  
  
  
@@ -404,24 +404,24 @@
     system overhead on those CPUs, including avoiding task load
     balancing if that is not needed.
  
-When the per-cpuset flag "sched_load_balance" is enabled (the default
-setting), it requests that all the CPUs in that cpusets allowed 'cpus'
+When the per-cpuset flag "cpuset.sched_load_balance" is enabled (the default
+setting), it requests that all the CPUs in that cpusets allowed 'cpuset.cpus'
 be contained in a single sched domain, ensuring that load balancing
 can move a task (not otherwised pinned, as by sched_setaffinity)
 from any CPU in that cpuset to any other.
  
-When the per-cpuset flag "sched_load_balance" is disabled, then the
+When the per-cpuset flag "cpuset.sched_load_balance" is disabled, then the
 scheduler will avoid load balancing across the CPUs in that cpuset,
 --except-- in so far as is necessary because some overlapping cpuset
 has "sched_load_balance" enabled.
  
-So, for example, if the top cpuset has the flag "sched_load_balance"
+So, for example, if the top cpuset has the flag "cpuset.sched_load_balance"
 enabled, then the scheduler will have one sched domain covering all
-CPUs, and the setting of the "sched_load_balance" flag in any other
+CPUs, and the setting of the "cpuset.sched_load_balance" flag in any other
 cpusets won't matter, as we're already fully load balancing.
  
 Therefore in the above two situations, the top cpuset flag
-"sched_load_balance" should be disabled, and only some of the smaller,
+"cpuset.sched_load_balance" should be disabled, and only some of the smaller,
 child cpusets have this flag enabled.
  
 When doing this, you don't usually want to leave any unpinned tasks in
@@ -433,7 +433,7 @@
 task to that underused CPU.
  
 Of course, tasks pinned to a particular CPU can be left in a cpuset
-that disables "sched_load_balance" as those tasks aren't going anywhere
+that disables "cpuset.sched_load_balance" as those tasks aren't going anywhere
 else anyway.
  
 There is an impedance mismatch here, between cpusets and sched domains.
  
  
@@ -443,19 +443,19 @@
 It is necessary for sched domains to be flat because load balancing
 across partially overlapping sets of CPUs would risk unstable dynamics
 that would be beyond our understanding.  So if each of two partially
-overlapping cpusets enables the flag 'sched_load_balance', then we
+overlapping cpusets enables the flag 'cpuset.sched_load_balance', then we
 form a single sched domain that is a superset of both.  We won't move
 a task to a CPU outside it cpuset, but the scheduler load balancing
 code might waste some compute cycles considering that possibility.
  
 This mismatch is why there is not a simple one-to-one relation
-between which cpusets have the flag "sched_load_balance" enabled,
+between which cpusets have the flag "cpuset.sched_load_balance" enabled,
 and the sched domain configuration.  If a cpuset enables the flag, it
 will get balancing across all its CPUs, but if it disables the flag,
 it will only be assured of no load balancing if no other overlapping
 cpuset enables the flag.
  
-If two cpusets have partially overlapping 'cpus' allowed, and only
+If two cpusets have partially overlapping 'cpuset.cpus' allowed, and only
 one of them has this flag enabled, then the other may find its
 tasks only partially load balanced, just on the overlapping CPUs.
 This is just the general case of the top_cpuset example given a few
  
  
  
@@ -468,23 +468,23 @@
 1.7.1 sched_load_balance implementation details.
 ------------------------------------------------
  
-The per-cpuset flag 'sched_load_balance' defaults to enabled (contrary
+The per-cpuset flag 'cpuset.sched_load_balance' defaults to enabled (contrary
 to most cpuset flags.)  When enabled for a cpuset, the kernel will
 ensure that it can load balance across all the CPUs in that cpuset
 (makes sure that all the CPUs in the cpus_allowed of that cpuset are
 in the same sched domain.)
  
-If two overlapping cpusets both have 'sched_load_balance' enabled,
+If two overlapping cpusets both have 'cpuset.sched_load_balance' enabled,
 then they will be (must be) both in the same sched domain.
  
-If, as is the default, the top cpuset has 'sched_load_balance' enabled,
+If, as is the default, the top cpuset has 'cpuset.sched_load_balance' enabled,
 then by the above that means there is a single sched domain covering
 the whole system, regardless of any other cpuset settings.
  
 The kernel commits to user space that it will avoid load balancing
 where it can.  It will pick as fine a granularity partition of sched
 domains as it can while still providing load balancing for any set
-of CPUs allowed to a cpuset having 'sched_load_balance' enabled.
+of CPUs allowed to a cpuset having 'cpuset.sched_load_balance' enabled.
  
 The internal kernel cpuset to scheduler interface passes from the
 cpuset code to the scheduler code a partition of the load balanced
  
@@ -495,9 +495,9 @@
 The cpuset code builds a new such partition and passes it to the
 scheduler sched domain setup code, to have the sched domains rebuilt
 as necessary, whenever:
- - the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes,
+ - the 'cpuset.sched_load_balance' flag of a cpuset with non-empty CPUs changes,
  - or CPUs come or go from a cpuset with this flag enabled,
- - or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs
+ - or 'cpuset.sched_relax_domain_level' value of a cpuset with non-empty CPUs
    and with this flag enabled changes,
  - or a cpuset with non-empty CPUs and with this flag enabled is removed,
  - or a cpu is offlined/onlined.
@@ -542,7 +542,7 @@
 on the next tick.  For some applications in special situation, waiting
 1 tick may be too long.
  
-The 'sched_relax_domain_level' file allows you to request changing
+The 'cpuset.sched_relax_domain_level' file allows you to request changing
 this searching range as you like.  This file takes int value which
 indicates size of searching range in levels ideally as follows,
 otherwise initial value -1 that indicates the cpuset has no request.
@@ -559,8 +559,8 @@
 can be changed using the relax_domain_level= boot parameter.
  
 This file is per-cpuset and affect the sched domain where the cpuset
-belongs to.  Therefore if the flag 'sched_load_balance' of a cpuset
-is disabled, then 'sched_relax_domain_level' have no effect since
+belongs to.  Therefore if the flag 'cpuset.sched_load_balance' of a cpuset
+is disabled, then 'cpuset.sched_relax_domain_level' have no effect since
 there is no sched domain belonging the cpuset.
  
 If multiple cpusets are overlapping and hence they form a single sched
  
@@ -607,9 +607,9 @@
 memory placement, as above, the next time that the kernel attempts
 to allocate a page of memory for that task.
  
-If a cpuset has its 'cpus' modified, then each task in that cpuset
+If a cpuset has its 'cpuset.cpus' modified, then each task in that cpuset
 will have its allowed CPU placement changed immediately.  Similarly,
-if a tasks pid is written to another cpusets 'tasks' file, then its
+if a tasks pid is written to another cpusets 'cpuset.tasks' file, then its
 allowed CPU placement is changed immediately.  If such a task had been
 bound to some subset of its cpuset using the sched_setaffinity() call,
 the task will be allowed to run on any CPU allowed in its new cpuset,
@@ -622,8 +622,8 @@
 Normally, once a page is allocated (given a physical page
 of main memory) then that page stays on whatever node it
 was allocated, so long as it remains allocated, even if the
-cpusets memory placement policy 'mems' subsequently changes.
-If the cpuset flag file 'memory_migrate' is set true, then when
+cpusets memory placement policy 'cpuset.mems' subsequently changes.
+If the cpuset flag file 'cpuset.memory_migrate' is set true, then when
 tasks are attached to that cpuset, any pages that task had
 allocated to it on nodes in its previous cpuset are migrated
 to the tasks new cpuset. The relative placement of the page within
  
@@ -631,12 +631,12 @@
 For example if the page was on the second valid node of the prior cpuset
 then the page will be placed on the second valid node of the new cpuset.
  
-Also if 'memory_migrate' is set true, then if that cpusets
-'mems' file is modified, pages allocated to tasks in that
-cpuset, that were on nodes in the previous setting of 'mems',
+Also if 'cpuset.memory_migrate' is set true, then if that cpusets
+'cpuset.mems' file is modified, pages allocated to tasks in that
+cpuset, that were on nodes in the previous setting of 'cpuset.mems',
 will be moved to nodes in the new setting of 'mems.'
 Pages that were not in the tasks prior cpuset, or in the cpusets
-prior 'mems' setting, will not be moved.
+prior 'cpuset.mems' setting, will not be moved.
  
 There is an exception to the above.  If hotplug functionality is used
 to remove all the CPUs that are currently assigned to a cpuset,
@@ -678,8 +678,8 @@
   cd /dev/cpuset
   mkdir Charlie
   cd Charlie
-  /bin/echo 2-3 > cpus
-  /bin/echo 1 > mems
+  /bin/echo 2-3 > cpuset.cpus
+  /bin/echo 1 > cpuset.mems
   /bin/echo $$ > tasks
   sh
   # The subshell 'sh' is now running in cpuset Charlie
@@ -725,10 +725,13 @@
  
 In this directory you can find several files:
 # ls
-cpu_exclusive  memory_migrate      mems                      tasks
-cpus           memory_pressure     notify_on_release
-mem_exclusive  memory_spread_page  sched_load_balance
-mem_hardwall   memory_spread_slab  sched_relax_domain_level
+cpuset.cpu_exclusive       cpuset.memory_spread_slab
+cpuset.cpus                cpuset.mems
+cpuset.mem_exclusive       cpuset.sched_load_balance
+cpuset.mem_hardwall        cpuset.sched_relax_domain_level
+cpuset.memory_migrate      notify_on_release
+cpuset.memory_pressure     tasks
+cpuset.memory_spread_page
  
 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
  
  
@@ -736,13 +739,13 @@
 the cpuset.
  
 Set some flags:
-# /bin/echo 1 > cpu_exclusive
+# /bin/echo 1 > cpuset.cpu_exclusive
  
 Add some cpus:
-# /bin/echo 0-7 > cpus
+# /bin/echo 0-7 > cpuset.cpus
  
 Add some mems:
-# /bin/echo 0-7 > mems
+# /bin/echo 0-7 > cpuset.mems
  
 Now attach your shell to this cpuset:
 # /bin/echo $$ > tasks
  
  
  
@@ -774,28 +777,28 @@
 This is the syntax to use when writing in the cpus or mems files
 in cpuset directories:
  
-# /bin/echo 1-4 > cpus		-> set cpus list to cpus 1,2,3,4
-# /bin/echo 1,2,3,4 > cpus	-> set cpus list to cpus 1,2,3,4
+# /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 > cpus	-> set cpus list to cpus 1,2,3,4,6
+# /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 "" > cpus		-> clear cpus list
+# /bin/echo "" > cpuset.cpus		-> clear cpus list
  
 2.3 Setting flags
 -----------------
  
 The syntax is very simple:
  
-# /bin/echo 1 > cpu_exclusive 	-> set flag 'cpu_exclusive'
-# /bin/echo 0 > cpu_exclusive 	-> unset flag 'cpu_exclusive'
+# /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
 -----------------------
...	...	@@ -168,20 +168,20 @@
168	168	containing (on top of the standard cgroup files) the following
169	169	files describing that cpuset:
170	170
171		- - cpus: list of CPUs in that cpuset
172		- - mems: list of Memory Nodes in that cpuset
173		- - memory_migrate flag: if set, move pages to cpusets nodes
174		- - cpu_exclusive flag: is cpu placement exclusive?
175		- - mem_exclusive flag: is memory placement exclusive?
176		- - mem_hardwall flag: is memory allocation hardwalled
177		- - memory_pressure: measure of how much paging pressure in cpuset
178		- - memory_spread_page flag: if set, spread page cache evenly on allowed nodes
179		- - memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
180		- - sched_load_balance flag: if set, load balance within CPUs on that cpuset
181		- - sched_relax_domain_level: the searching range when migrating tasks
	171	+ - cpuset.cpus: list of CPUs in that cpuset
	172	+ - cpuset.mems: list of Memory Nodes in that cpuset
	173	+ - cpuset.memory_migrate flag: if set, move pages to cpusets nodes
	174	+ - cpuset.cpu_exclusive flag: is cpu placement exclusive?
	175	+ - cpuset.mem_exclusive flag: is memory placement exclusive?
	176	+ - cpuset.mem_hardwall flag: is memory allocation hardwalled
	177	+ - cpuset.memory_pressure: measure of how much paging pressure in cpuset
	178	+ - cpuset.memory_spread_page flag: if set, spread page cache evenly on allowed nodes
	179	+ - cpuset.memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
	180	+ - cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset
	181	+ - cpuset.sched_relax_domain_level: the searching range when migrating tasks
182	182
183	183	In addition, the root cpuset only has the following file:
184		- - memory_pressure_enabled flag: compute memory_pressure?
	184	+ - cpuset.memory_pressure_enabled flag: compute memory_pressure?
185	185
186	186	New cpusets are created using the mkdir system call or shell
187	187	command. The properties of a cpuset, such as its flags, allowed
...	...	@@ -229,7 +229,7 @@
229	229	a direct ancestor or descendant, may share any of the same CPUs or
230	230	Memory Nodes.
231	231
232		-A cpuset that is mem_exclusive or mem_hardwall is "hardwalled",
	232	+A cpuset that is cpuset.mem_exclusive or cpuset.mem_hardwall is "hardwalled",
233	233	i.e. it restricts kernel allocations for page, buffer and other data
234	234	commonly shared by the kernel across multiple users. All cpusets,
235	235	whether hardwalled or not, restrict allocations of memory for user
236	236
237	237
...	...	@@ -304,15 +304,15 @@
304	304	---------------------------
305	305	There are two boolean flag files per cpuset that control where the
306	306	kernel allocates pages for the file system buffers and related in
307		-kernel data structures. They are called 'memory_spread_page' and
308		-'memory_spread_slab'.
	307	+kernel data structures. They are called 'cpuset.memory_spread_page' and
	308	+'cpuset.memory_spread_slab'.
309	309
310		-If the per-cpuset boolean flag file 'memory_spread_page' is set, then
	310	+If the per-cpuset boolean flag file 'cpuset.memory_spread_page' is set, then
311	311	the kernel will spread the file system buffers (page cache) evenly
312	312	over all the nodes that the faulting task is allowed to use, instead
313	313	of preferring to put those pages on the node where the task is running.
314	314
315		-If the per-cpuset boolean flag file 'memory_spread_slab' is set,
	315	+If the per-cpuset boolean flag file 'cpuset.memory_spread_slab' is set,
316	316	then the kernel will spread some file system related slab caches,
317	317	such as for inodes and dentries evenly over all the nodes that the
318	318	faulting task is allowed to use, instead of preferring to put those
319	319
320	320
...	...	@@ -337,21 +337,21 @@
337	337	is turned off, then the currently specified NUMA mempolicy once again
338	338	applies to memory page allocations.
339	339
340		-Both 'memory_spread_page' and 'memory_spread_slab' are boolean flag
	340	+Both 'cpuset.memory_spread_page' and 'cpuset.memory_spread_slab' are boolean flag
341	341	files. By default they contain "0", meaning that the feature is off
342	342	for that cpuset. If a "1" is written to that file, then that turns
343	343	the named feature on.
344	344
345	345	The implementation is simple.
346	346
347		-Setting the flag 'memory_spread_page' turns on a per-process flag
	347	+Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
348	348	PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
349	349	joins that cpuset. The page allocation calls for the page cache
350	350	is modified to perform an inline check for this PF_SPREAD_PAGE task
351	351	flag, and if set, a call to a new routine cpuset_mem_spread_node()
352	352	returns the node to prefer for the allocation.
353	353
354		-Similarly, setting 'memory_spread_slab' turns on the flag
	354	+Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
355	355	PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
356	356	pages from the node returned by cpuset_mem_spread_node().
357	357
358	358
359	359
360	360
361	361
...	...	@@ -404,24 +404,24 @@
404	404	system overhead on those CPUs, including avoiding task load
405	405	balancing if that is not needed.
406	406
407		-When the per-cpuset flag "sched_load_balance" is enabled (the default
408		-setting), it requests that all the CPUs in that cpusets allowed 'cpus'
	407	+When the per-cpuset flag "cpuset.sched_load_balance" is enabled (the default
	408	+setting), it requests that all the CPUs in that cpusets allowed 'cpuset.cpus'
409	409	be contained in a single sched domain, ensuring that load balancing
410	410	can move a task (not otherwised pinned, as by sched_setaffinity)
411	411	from any CPU in that cpuset to any other.
412	412
413		-When the per-cpuset flag "sched_load_balance" is disabled, then the
	413	+When the per-cpuset flag "cpuset.sched_load_balance" is disabled, then the
414	414	scheduler will avoid load balancing across the CPUs in that cpuset,
415	415	--except-- in so far as is necessary because some overlapping cpuset
416	416	has "sched_load_balance" enabled.
417	417
418		-So, for example, if the top cpuset has the flag "sched_load_balance"
	418	+So, for example, if the top cpuset has the flag "cpuset.sched_load_balance"
419	419	enabled, then the scheduler will have one sched domain covering all
420		-CPUs, and the setting of the "sched_load_balance" flag in any other
	420	+CPUs, and the setting of the "cpuset.sched_load_balance" flag in any other
421	421	cpusets won't matter, as we're already fully load balancing.
422	422
423	423	Therefore in the above two situations, the top cpuset flag
424		-"sched_load_balance" should be disabled, and only some of the smaller,
	424	+"cpuset.sched_load_balance" should be disabled, and only some of the smaller,
425	425	child cpusets have this flag enabled.
426	426
427	427	When doing this, you don't usually want to leave any unpinned tasks in
...	...	@@ -433,7 +433,7 @@
433	433	task to that underused CPU.
434	434
435	435	Of course, tasks pinned to a particular CPU can be left in a cpuset
436		-that disables "sched_load_balance" as those tasks aren't going anywhere
	436	+that disables "cpuset.sched_load_balance" as those tasks aren't going anywhere
437	437	else anyway.
438	438
439	439	There is an impedance mismatch here, between cpusets and sched domains.
440	440
441	441
...	...	@@ -443,19 +443,19 @@
443	443	It is necessary for sched domains to be flat because load balancing
444	444	across partially overlapping sets of CPUs would risk unstable dynamics
445	445	that would be beyond our understanding. So if each of two partially
446		-overlapping cpusets enables the flag 'sched_load_balance', then we
	446	+overlapping cpusets enables the flag 'cpuset.sched_load_balance', then we
447	447	form a single sched domain that is a superset of both. We won't move
448	448	a task to a CPU outside it cpuset, but the scheduler load balancing
449	449	code might waste some compute cycles considering that possibility.
450	450
451	451	This mismatch is why there is not a simple one-to-one relation
452		-between which cpusets have the flag "sched_load_balance" enabled,
	452	+between which cpusets have the flag "cpuset.sched_load_balance" enabled,
453	453	and the sched domain configuration. If a cpuset enables the flag, it
454	454	will get balancing across all its CPUs, but if it disables the flag,
455	455	it will only be assured of no load balancing if no other overlapping
456	456	cpuset enables the flag.
457	457
458		-If two cpusets have partially overlapping 'cpus' allowed, and only
	458	+If two cpusets have partially overlapping 'cpuset.cpus' allowed, and only
459	459	one of them has this flag enabled, then the other may find its
460	460	tasks only partially load balanced, just on the overlapping CPUs.
461	461	This is just the general case of the top_cpuset example given a few
462	462
463	463
464	464
...	...	@@ -468,23 +468,23 @@
468	468	1.7.1 sched_load_balance implementation details.
469	469	------------------------------------------------
470	470
471		-The per-cpuset flag 'sched_load_balance' defaults to enabled (contrary
	471	+The per-cpuset flag 'cpuset.sched_load_balance' defaults to enabled (contrary
472	472	to most cpuset flags.) When enabled for a cpuset, the kernel will
473	473	ensure that it can load balance across all the CPUs in that cpuset
474	474	(makes sure that all the CPUs in the cpus_allowed of that cpuset are
475	475	in the same sched domain.)
476	476
477		-If two overlapping cpusets both have 'sched_load_balance' enabled,
	477	+If two overlapping cpusets both have 'cpuset.sched_load_balance' enabled,
478	478	then they will be (must be) both in the same sched domain.
479	479
480		-If, as is the default, the top cpuset has 'sched_load_balance' enabled,
	480	+If, as is the default, the top cpuset has 'cpuset.sched_load_balance' enabled,
481	481	then by the above that means there is a single sched domain covering
482	482	the whole system, regardless of any other cpuset settings.
483	483
484	484	The kernel commits to user space that it will avoid load balancing
485	485	where it can. It will pick as fine a granularity partition of sched
486	486	domains as it can while still providing load balancing for any set
487		-of CPUs allowed to a cpuset having 'sched_load_balance' enabled.
	487	+of CPUs allowed to a cpuset having 'cpuset.sched_load_balance' enabled.
488	488
489	489	The internal kernel cpuset to scheduler interface passes from the
490	490	cpuset code to the scheduler code a partition of the load balanced
491	491
...	...	@@ -495,9 +495,9 @@
495	495	The cpuset code builds a new such partition and passes it to the
496	496	scheduler sched domain setup code, to have the sched domains rebuilt
497	497	as necessary, whenever:
498		- - the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes,
	498	+ - the 'cpuset.sched_load_balance' flag of a cpuset with non-empty CPUs changes,
499	499	- or CPUs come or go from a cpuset with this flag enabled,
500		- - or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs
	500	+ - or 'cpuset.sched_relax_domain_level' value of a cpuset with non-empty CPUs
501	501	and with this flag enabled changes,
502	502	- or a cpuset with non-empty CPUs and with this flag enabled is removed,
503	503	- or a cpu is offlined/onlined.
...	...	@@ -542,7 +542,7 @@
542	542	on the next tick. For some applications in special situation, waiting
543	543	1 tick may be too long.
544	544
545		-The 'sched_relax_domain_level' file allows you to request changing
	545	+The 'cpuset.sched_relax_domain_level' file allows you to request changing
546	546	this searching range as you like. This file takes int value which
547	547	indicates size of searching range in levels ideally as follows,
548	548	otherwise initial value -1 that indicates the cpuset has no request.
...	...	@@ -559,8 +559,8 @@
559	559	can be changed using the relax_domain_level= boot parameter.
560	560
561	561	This file is per-cpuset and affect the sched domain where the cpuset
562		-belongs to. Therefore if the flag 'sched_load_balance' of a cpuset
563		-is disabled, then 'sched_relax_domain_level' have no effect since
	562	+belongs to. Therefore if the flag 'cpuset.sched_load_balance' of a cpuset
	563	+is disabled, then 'cpuset.sched_relax_domain_level' have no effect since
564	564	there is no sched domain belonging the cpuset.
565	565
566	566	If multiple cpusets are overlapping and hence they form a single sched
567	567
...	...	@@ -607,9 +607,9 @@
607	607	memory placement, as above, the next time that the kernel attempts
608	608	to allocate a page of memory for that task.
609	609
610		-If a cpuset has its 'cpus' modified, then each task in that cpuset
	610	+If a cpuset has its 'cpuset.cpus' modified, then each task in that cpuset
611	611	will have its allowed CPU placement changed immediately. Similarly,
612		-if a tasks pid is written to another cpusets 'tasks' file, then its
	612	+if a tasks pid is written to another cpusets 'cpuset.tasks' file, then its
613	613	allowed CPU placement is changed immediately. If such a task had been
614	614	bound to some subset of its cpuset using the sched_setaffinity() call,
615	615	the task will be allowed to run on any CPU allowed in its new cpuset,
...	...	@@ -622,8 +622,8 @@
622	622	Normally, once a page is allocated (given a physical page
623	623	of main memory) then that page stays on whatever node it
624	624	was allocated, so long as it remains allocated, even if the
625		-cpusets memory placement policy 'mems' subsequently changes.
626		-If the cpuset flag file 'memory_migrate' is set true, then when
	625	+cpusets memory placement policy 'cpuset.mems' subsequently changes.
	626	+If the cpuset flag file 'cpuset.memory_migrate' is set true, then when
627	627	tasks are attached to that cpuset, any pages that task had
628	628	allocated to it on nodes in its previous cpuset are migrated
629	629	to the tasks new cpuset. The relative placement of the page within
630	630
...	...	@@ -631,12 +631,12 @@
631	631	For example if the page was on the second valid node of the prior cpuset
632	632	then the page will be placed on the second valid node of the new cpuset.
633	633
634		-Also if 'memory_migrate' is set true, then if that cpusets
635		-'mems' file is modified, pages allocated to tasks in that
636		-cpuset, that were on nodes in the previous setting of 'mems',
	634	+Also if 'cpuset.memory_migrate' is set true, then if that cpusets
	635	+'cpuset.mems' file is modified, pages allocated to tasks in that
	636	+cpuset, that were on nodes in the previous setting of 'cpuset.mems',
637	637	will be moved to nodes in the new setting of 'mems.'
638	638	Pages that were not in the tasks prior cpuset, or in the cpusets
639		-prior 'mems' setting, will not be moved.
	639	+prior 'cpuset.mems' setting, will not be moved.
640	640
641	641	There is an exception to the above. If hotplug functionality is used
642	642	to remove all the CPUs that are currently assigned to a cpuset,
...	...	@@ -678,8 +678,8 @@
678	678	cd /dev/cpuset
679	679	mkdir Charlie
680	680	cd Charlie
681		- /bin/echo 2-3 > cpus
682		- /bin/echo 1 > mems
	681	+ /bin/echo 2-3 > cpuset.cpus
	682	+ /bin/echo 1 > cpuset.mems
683	683	/bin/echo $$ > tasks
684	684	sh
685	685	# The subshell 'sh' is now running in cpuset Charlie
...	...	@@ -725,10 +725,13 @@
725	725
726	726	In this directory you can find several files:
727	727	# ls
728		-cpu_exclusive memory_migrate mems tasks
729		-cpus memory_pressure notify_on_release
730		-mem_exclusive memory_spread_page sched_load_balance
731		-mem_hardwall memory_spread_slab sched_relax_domain_level
	728	+cpuset.cpu_exclusive cpuset.memory_spread_slab
	729	+cpuset.cpus cpuset.mems
	730	+cpuset.mem_exclusive cpuset.sched_load_balance
	731	+cpuset.mem_hardwall cpuset.sched_relax_domain_level
	732	+cpuset.memory_migrate notify_on_release
	733	+cpuset.memory_pressure tasks
	734	+cpuset.memory_spread_page
732	735
733	736	Reading them will give you information about the state of this cpuset:
734	737	the CPUs and Memory Nodes it can use, the processes that are using
735	738
736	739
...	...	@@ -736,13 +739,13 @@
736	739	the cpuset.
737	740
738	741	Set some flags:
739		-# /bin/echo 1 > cpu_exclusive
	742	+# /bin/echo 1 > cpuset.cpu_exclusive
740	743
741	744	Add some cpus:
742		-# /bin/echo 0-7 > cpus
	745	+# /bin/echo 0-7 > cpuset.cpus
743	746
744	747	Add some mems:
745		-# /bin/echo 0-7 > mems
	748	+# /bin/echo 0-7 > cpuset.mems
746	749
747	750	Now attach your shell to this cpuset:
748	751	# /bin/echo $$ > tasks
749	752
750	753
751	754
...	...	@@ -774,28 +777,28 @@
774	777	This is the syntax to use when writing in the cpus or mems files
775	778	in cpuset directories:
776	779
777		-# /bin/echo 1-4 > cpus -> set cpus list to cpus 1,2,3,4
778		-# /bin/echo 1,2,3,4 > cpus -> set cpus list to cpus 1,2,3,4
	780	+# /bin/echo 1-4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
	781	+# /bin/echo 1,2,3,4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
779	782
780	783	To add a CPU to a cpuset, write the new list of CPUs including the
781	784	CPU to be added. To add 6 to the above cpuset:
782	785
783		-# /bin/echo 1-4,6 > cpus -> set cpus list to cpus 1,2,3,4,6
	786	+# /bin/echo 1-4,6 > cpuset.cpus -> set cpus list to cpus 1,2,3,4,6
784	787
785	788	Similarly to remove a CPU from a cpuset, write the new list of CPUs
786	789	without the CPU to be removed.
787	790
788	791	To remove all the CPUs:
789	792
790		-# /bin/echo "" > cpus -> clear cpus list
	793	+# /bin/echo "" > cpuset.cpus -> clear cpus list
791	794
792	795	2.3 Setting flags
793	796	-----------------
794	797
795	798	The syntax is very simple:
796	799
797		-# /bin/echo 1 > cpu_exclusive -> set flag 'cpu_exclusive'
798		-# /bin/echo 0 > cpu_exclusive -> unset flag 'cpu_exclusive'
	800	+# /bin/echo 1 > cpuset.cpu_exclusive -> set flag 'cpuset.cpu_exclusive'
	801	+# /bin/echo 0 > cpuset.cpu_exclusive -> unset flag 'cpuset.cpu_exclusive'
799	802
800	803	2.4 Attaching processes
801	804	-----------------------