Lines Matching refs:can

34 can host any number of controllers.  While this seems to provide a
38 type controllers such as freezer which can be useful in all
39 hierarchies can only be used in one.  The issue is exacerbated by the
40 fact that controllers can't be moved around once hierarchies are
45 In practice, these issues heavily limit which controllers can be put
56 restricts how cgroup is used in general and what controllers can do.
59 that a task's cgroup membership can't be described in finite length.
65 Also, as a controller can't have any expectation regarding what shape
91 Currently, unified hierarchy can be mounted with the following mount
100 root of unified hierarchy can be bound to other hierarchies.  This
110 A controller can be moved across hierarchies only after the controller
159 controllers which can be enabled in the cgroup's
168 from the parent can be used in its children.
176 all non-root "cgroup.subtree_control" files can only contain
178 file.  A controller can be enabled only if the parent has the
179 controller enabled and a controller can't be disabled if one or more
236 consumption which can't be associated with any other cgroup and
253 subhierarchy becomes empty so that it can be cleaned up.  cgroup
276 which can be used to monitor whether the cgroup's subhierarchy has
282 delegating management of subhierarchy - subhierarchy monitoring can
321 - A task can be moved into an empty cpuset, and again it takes on the
358   limit that can not budge, even if the OOM killer has to be called.
368   The memory.high boundary on the other hand can be set much more
373   lead to gradual performance degradation.  The user can monitor this
379   can be exceeded.  But even then it's mostly better to satisfy the
401   Very High Number, and a configured limit can be unset by echoing -1
403   architecture dependent and not very descriptive.  And while -1 can
441 details in a way which can exert significant pain by locking the
442 kernel into a contract that can't be maintained in a reasonable