Hi > > > As Alan Cox suggested/wondered in this thread, > > > http://lkml.org/lkml/2009/1/12/235 , this is a container group based approach > > > to override the oom killer selection without losing all the benefits of the > > > current oom killer heuristics and oom_adj interface. > > > > > > It adds a tunable oom.victim to the oom cgroup. The oom killer will kill the > > > process using the usual badness value but only within the cgroup with the > > > maximum value for oom.victim before killing any process from a cgroup with a > > > lesser oom.victim number. Oom killing could be disabled by setting > > > oom.victim=0. > > > > Looking at the patch, I wonder if it is time for user space OOM > > notifications that were discussed during the containers mini-summit. > > The idea is to inform user space about OOM's and let user space take > > action, if no action is taken, the default handler kicks in. > > The OLPC folks (Marcelo I believe) posted code for this and I believe > OLPC is using this functionality internally so that under memory pressure > (before we actually hit OOM) programs can respond by doing stuff like > evicting caches. Confused. As far as I know, people want the method of flexible cache treating. but oom seems less flexible than userland notification. Why do you think notification is bad? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers