On Fri 20-04-12 00:33:18, Johannes Weiner wrote: > On Thu, Apr 19, 2012 at 10:47:27AM -0700, Ying Han wrote: > > On Thu, Apr 19, 2012 at 10:04 AM, Michal Hocko <mhocko@xxxxxxx> wrote: [...] > > > Hmm, I guess that both approaches have cons and pros. > > > * Hierarchical soft limit reclaim - reclaim the whole subtree of the over > > > soft limit memcg > > > + it is consistent with the hard limit reclaim > > Not sure why we want them to be consistent. Soft_limit is serving > > different purpose and the one of the main purpose is to preserve the > > working set of the cgroup. > > I'd argue, given the history of cgroups, one of the main purposes is > having a machine of containers where you overcommit their hard limit > and set the soft limit accordingly to provide fairness. > > Yes, we don't want to reclaim hierarchies that are below their soft > limit as long as there are some in excess, of course. This is a flaw > and needs fixing. But it's something completely different than > changing how the soft limit is defined and suddenly allow child > groups, which you may not trust, to override rules defined by parental > groups. As I wrote in other email. Who is allowed to set the limit? Owner of the container? If yes then how is admin supposed to set the top limit for the container? Default (0) will not work, right? > > It bothers me that we should add something that will almost certainly > bite us in the future while we are discussing on the cgroups list what > would stand in the way of getting sane hierarchy semantics across > controllers to provide consistency, nesting, etc. > > To support a single use case, which I feel we still have not discussed > nearly enough to justify this change. > > For example, I get that you want 'meta-groups' that group together > subgroups for common accounting and hard limiting. But I don't see > why such meta-groups have their own processes. Conceptually, I mean, > how does a process fit into A? Is it superior to the tasks in A1 and > A2? Why can't it live in A3? That was my thinking as well but it will get harder if we really want to have the unified hierarchy for all controllers. Consider a school lab and per-user group which basically limits cpu bandwidth and maximum amount of memory by hard limit (soft limit 0). If a user would like to run a workload which would benefit from resident memory he could create a subgroup and set a soft limit. All other tasks would be executed in his native group by default because we probably do not want him to think about cgroups for all tasks. [...] -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>