On Fri 23-02-18 00:23:53, Balbir Singh wrote: > On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Thu 22-02-18 13:54:46, Balbir Singh wrote: > > [...] > >> 2. Memory cgroups - I don't see a pressing need for many new features, > >> but I'd like to see if we can revive some old proposals around virtual > >> memory limits > > > > Could you be more specific about usecase(s)? > > I had for a long time a virtual memory limit controller in -mm tree. > The use case was to fail allocations as opposed to OOM'ing in the > worst case as we do with the cgroup memory limits (actual page usage > control). I did not push for it then since I got side-tracked. I'd > like to pursue a use case for being able to fail allocations as > opposed to OOM'ing on a per cgroup basis. I'd like to start the > discussion again. So you basically want the strict no overcommit on the per memcg level? I am really skeptical, to be completely honest. The global behavior is not very usable in most cases already. Making it per-memcg will just amplify all the issues (application tend to overcommit their virtual address space). Not to mention that you cannot really prevent from the OOM killer because there are allocations outside of the address space. So if you want to push this forward you really need a very good existing usecase to justifiy the change. -- Michal Hocko SUSE Labs -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
