On Tue, 3 Aug 2010, KAMEZAWA Hiroyuki wrote: > > > Not at all, the user knows what tasks are attached to the memcg and can > > > easily determine which task is going to be killed when it ooms: simply > > > iterate through the memcg tasklist, check /proc/pid/oom_score, and sort. > > > > > > > And finds > > at system oom, process A is killed. > > at memcg oom, process B is killed. > > > > funny non-deteministic interace, aha. > > > > I said > - you have beutiful legs. (new logic of oom calculation) > - but your face is ugly (new oom_score_adj) > then > - I bought a mask for you (oom_disable for memcg.) > > Then, please don't use your time for convince me your face is beutiful. > It's waste of time. > Haha, I love the analogy :) The difference in selection of tasks depending on whether its a memcg or system oom isn't really concerning since /proc/pid/oom_score_adj would have been assigned in a way that reflects its prioritization for kill only in the memcg oom kill scenario. It would reflect the prioritization system wide if memcg were not used. The same thing would happen if several tasks in different memcgs were given oom_score_adj of +1000. This would yield a badness score of 1000 for each of those tasks, which translates to "always kill." Only one would actually be selected for kill in the system wide case, however, to prevent needless killing. Which one that is happens to be the one that appears in the tasklist first. The end result is that when using memcg, we don't really care about the prioritization of killing of tasks when the entire system is oom. That's true because no memcg happens to be oom itself, we've simply run out of RAM. The same is true of cpusets. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>