On Wed, 9 Mar 2011, KAMEZAWA Hiroyuki wrote: > For me, I want an oom-killall module Or oom-SIGSTOP-all module. > oom-killall will be useful for killing fork-bombs and very quick recovery. > That doesn't need to be in kernelspace, though, the global oom killer will give access to memory reserves to any task that invokes it that has a pending SIGKILL, so we could extend that to the memcg oom killer as well and then use an oom notifier to trigger a killall in userspace. > For me, the 1st motivation of oom-disable is to taking core-dump of > memory leaking process and look into it for checking memory leak. > (panic_on_oom -> kdump is used for supporting my customer.) > I remember your advocacy of panic_on_oom during the oom killer rewrite discussion, this makes it more clear. > Anyway, if you add notifier, please give us a user of it. If possible, > it should be a function which can never be implemented in userland even > with sane programmers, admins, and users. > > For example, if all process's oom_score_adj was set to -1000 and oom-killer > doesn't work, do you implement a timeout ? I think you'll say it's a > wrong configuration. memcg's oom_disable timeout is the same thing. > You know me quite well, actually :) We've agreed to drop this patch and carry it internally until we can deprecate it and implement a separate oom handling thread in the root memcg that will detect the situation for a given period of time (either via an oom notifier or by checking that the usage of the memcg of interest equals to the limit) and then do the killall. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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>