* KOSAKI Motohiro <kosaki.motoh...@jp.fujitsu.com> [2009-01-27 16:02:34]:
> 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. > I did see the patches on linux-mm, but a more generic cgroup patch would help both cases, in the absence of cgroups, the default cgroup will contain all tasks and can carry out the handling. > 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? I did not find Alan's message confusing or stating that notification was bad, but I might be misreading it. -- Balbir _______________________________________________ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
