On Fri, Jan 16, 2009 at 5:44 AM, Chris Samuel <chris@xxxxxxxxxxx> wrote > > > From 1746154e424d0f0e404ec9f3bec081d2f98088b6 Mon Sep 17 00:00:00 2001 > From: Chris Samuel <chris@xxxxxxxxxxx> > Date: Sat, 17 Jan 2009 00:01:18 +1100 > Subject: [PATCH] cgroups: documentation typo and spelling corrections > > Minor typo and spelling corrections fixed whilst reading > to learn about cgroups capabilities. > > Signed-off-by: Chris Samuel <chris@xxxxxxxxxxx> Acked-by: Paul Menage <menage@xxxxxxxxxx> Thanks. > --- > Documentation/cgroups/cgroups.txt | 10 +++++----- > Documentation/cgroups/cpusets.txt | 12 ++++++------ > Documentation/cgroups/devices.txt | 2 +- > Documentation/cgroups/memory.txt | 2 +- > 4 files changed, 13 insertions(+), 13 deletions(-) > > diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt > index d9e5d6f..d79146e 100644 > --- a/Documentation/cgroups/cgroups.txt > +++ b/Documentation/cgroups/cgroups.txt > @@ -56,7 +56,7 @@ hierarchy, and a set of subsystems; each subsystem has system-specific > state attached to each cgroup in the hierarchy. Each hierarchy has > an instance of the cgroup virtual filesystem associated with it. > > -At any one time there may be multiple active hierachies of task > +At any one time there may be multiple active hierarchies of task > cgroups. Each hierarchy is a partition of all tasks in the system. > > User level code may create and destroy cgroups by name in an > @@ -124,10 +124,10 @@ following lines: > / \ > Prof (15%) students (5%) > > -Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go > +Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go > into NFS network class. > > -At the same time firefox/lynx will share an appropriate CPU/Memory class > +At the same time Firefox/Lynx will share an appropriate CPU/Memory class > depending on who launched it (prof/student). > > With the ability to classify tasks differently for different resources > @@ -327,7 +327,7 @@ and then start a subshell 'sh' in that cgroup: > Creating, modifying, using the cgroups can be done through the cgroup > virtual filesystem. > > -To mount a cgroup hierarchy will all available subsystems, type: > +To mount a cgroup hierarchy with all available subsystems, type: > # mount -t cgroup xxx /dev/cgroup > > The "xxx" is not interpreted by the cgroup code, but will appear in > @@ -523,7 +523,7 @@ always handled well. > void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) > (cgroup_mutex held by caller) > > -Called at the end of cgroup_clone() to do any paramater > +Called at the end of cgroup_clone() to do any parameter > initialization which might be required before a task could attach. For > example in cpusets, no task may attach before 'cpus' and 'mems' are set > up. > diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt > index 5c86c25..657229b 100644 > --- a/Documentation/cgroups/cpusets.txt > +++ b/Documentation/cgroups/cpusets.txt > @@ -131,7 +131,7 @@ Cpusets extends these two mechanisms as follows: > - The hierarchy of cpusets can be mounted at /dev/cpuset, for > browsing and manipulation from user space. > - A cpuset may be marked exclusive, which ensures that no other > - cpuset (except direct ancestors and descendents) may contain > + cpuset (except direct ancestors and descendants) may contain > any overlapping CPUs or Memory Nodes. > - You can list all the tasks (by pid) attached to any cpuset. > > @@ -222,7 +222,7 @@ nodes with memory--using the cpuset_track_online_nodes() hook. > -------------------------------- > > If a cpuset is cpu or mem exclusive, no other cpuset, other than > -a direct ancestor or descendent, may share any of the same CPUs or > +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", > @@ -423,7 +423,7 @@ child cpusets have this flag enabled. > When doing this, you don't usually want to leave any unpinned tasks in > the top cpuset that might use non-trivial amounts of CPU, as such tasks > may be artificially constrained to some subset of CPUs, depending on > -the particulars of this flag setting in descendent cpusets. Even if > +the particulars of this flag setting in descendant cpusets. Even if > such a task could use spare CPU cycles in some other CPUs, the kernel > scheduler might not consider the possibility of load balancing that > task to that underused CPU. > @@ -522,9 +522,9 @@ be idle. > > Of course it takes some searching cost to find movable tasks and/or > idle CPUs, the scheduler might not search all CPUs in the domain > -everytime. In fact, in some architectures, the searching ranges on > +every time. In fact, in some architectures, the searching ranges on > events are limited in the same socket or node where the CPU locates, > -while the load balance on tick searchs all. > +while the load balance on tick searches all. > > For example, assume CPU Z is relatively far from CPU X. Even if CPU Z > is idle while CPU X and the siblings are busy, scheduler can't migrate > @@ -592,7 +592,7 @@ its new cpuset, then the task will continue to use whatever subset > of MPOL_BIND nodes are still allowed in the new cpuset. If the task > was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed > in the new cpuset, then the task will be essentially treated as if it > -was MPOL_BIND bound to the new cpuset (even though its numa placement, > +was MPOL_BIND bound to the new cpuset (even though its NUMA placement, > as queried by get_mempolicy(), doesn't change). If a task is moved > from one cpuset to another, then the kernel will adjust the tasks > memory placement, as above, the next time that the kernel attempts > diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt > index 7cc6e6a..57ca4c8 100644 > --- a/Documentation/cgroups/devices.txt > +++ b/Documentation/cgroups/devices.txt > @@ -42,7 +42,7 @@ suffice, but we can decide the best way to adequately restrict > movement as people get some experience with this. We may just want > to require CAP_SYS_ADMIN, which at least is a separate bit from > CAP_MKNOD. We may want to just refuse moving to a cgroup which > -isn't a descendent of the current one. Or we may want to use > +isn't a descendant of the current one. Or we may want to use > CAP_MAC_ADMIN, since we really are trying to lock down root. > > CAP_SYS_ADMIN is needed to modify the whitelist or move another > diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt > index e150196..a98a7fe 100644 > --- a/Documentation/cgroups/memory.txt > +++ b/Documentation/cgroups/memory.txt > @@ -302,7 +302,7 @@ will be charged as a new owner of it. > unevictable - # of pages cannot be reclaimed.(mlocked etc) > > Below is depend on CONFIG_DEBUG_VM. > - inactive_ratio - VM inernal parameter. (see mm/page_alloc.c) > + inactive_ratio - VM internal parameter. (see mm/page_alloc.c) > recent_rotated_anon - VM internal parameter. (see mm/vmscan.c) > recent_rotated_file - VM internal parameter. (see mm/vmscan.c) > recent_scanned_anon - VM internal parameter. (see mm/vmscan.c) > -- > 1.5.6.3 > > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > > This email may come with a PGP signature as a file. Do not panic. > For more info see: http://en.wikipedia.org/wiki/OpenPGP > > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
