> > having said that, if you decide to put too large tasks into > > a cgroup with too small limit, i don't think that there are > > many choices besides OOM-kill and allowing "exceed". > > > IMHO, allowing exceed is harmfull without changing the definition of "limit". > "limit" is hard-limit, now, not soft-limit. Changing the defintion just for > this is not acceptable for me. even with the current code, the "exceed" condition can be created by simply lowering the limit. (well, i know that some of your patches floating around change it.) > Maybe "move" under limit itself is crazy ops....Hmm... > > Should we allow task move when the destination cgroup is unlimited ? > Isn't it useful ? i think it makes some sense. > > actually, i think that #3 and #5 are somewhat similar. > > a big difference is that, while #5 shrinks the cgroup immediately, > > #3 does it later. in case we need to do OOM-kill, i prefer to do it > > sooner than later. > > > #3 will not cause OOM-killer, I hope...A user can notice memory shortage. we are talking about the case where a cgroup's working set is getting hopelessly larger than its limit. i don't see why #3 will not cause OOM-kill. can you explain? YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
