On Tue 16-10-12 14:16:51, Glauber Costa wrote: > Signed-off-by: Glauber Costa <[email protected]> > CC: Frederic Weisbecker <[email protected]> > CC: Kamezawa Hiroyuki <[email protected]> > CC: Michal Hocko <[email protected]> > CC: Christoph Lameter <[email protected]> > CC: Pekka Enberg <[email protected]> > CC: Johannes Weiner <[email protected]> > CC: Suleiman Souhlal <[email protected]> > CC: Tejun Heo <[email protected]>
Acked-by: Michal Hocko <[email protected] Just a nit.. > --- > Documentation/cgroups/memory.txt | 58 > +++++++++++++++++++++++++++++++++++++++- > 1 file changed, 57 insertions(+), 1 deletion(-) > > diff --git a/Documentation/cgroups/memory.txt > b/Documentation/cgroups/memory.txt > index c07f7b4..dd15be8 100644 > --- a/Documentation/cgroups/memory.txt > +++ b/Documentation/cgroups/memory.txt [...] > @@ -268,20 +273,65 @@ the amount of kernel memory used by the system. Kernel > memory is fundamentally > different than user memory, since it can't be swapped out, which makes it > possible to DoS the system by consuming too much of this precious resource. > > +Kernel memory won't be accounted at all until limit on a group is set. This > +allows for existing setups to continue working without disruption. The limit > +cannot be set if the cgroup have children, or if there are already tasks in > the > +cgroup. When use_hierarchy == 1 and a group is accounted, its children will > +automatically be accounted regardless of their limit value. > + > +After a controller is first limited, it will be kept being accounted until it s/controller/group/ > +is removed. The memory limitation itself, can of course be removed by writing > +-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but > not > +limited. > + -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
