On Mon, 21 Jun 2010, KOSAKI Motohiro wrote: > > Of course it does, it actually has units whereas oom_adj only grows or > > shrinks the badness score exponentially. oom_score_adj's units are well > > understood: on a machine with 4G of memory, 250 means we're trying to > > prejudice it by 1G of memory so that can be used by other tasks, -250 > > means other tasks should be prejudiced by 1G in comparison to this task, > > etc. It's actually quite powerful. > > And, no real user want such power. > Google does, and I imagine other users will want to be able to normalize each task's memory usage against the others. It's perfectly legitimate for one task to consume 3G while another consumes 1G and want to select the 1G task to kill. Setting the 3G task's oom_score_adj value in this case to be -250, for example, depending on the memory capacity of the machine, makes much more sense than influencing it as a bitshift on top of a vastly unpredictable heuristic with oom_adj. This seems rather trivial to understand. > When we consider desktop user case, End-users don't use oom_adj by themself. > their application are using it. It mean now oom_adj behave as syscall like > system interface, unlike kernel knob. application developers also don't > need oom_score_adj because application developers don't know end-users > machine mem size. > I agree, oom_score_adj isn't targeted to the desktop nor is it targeted to application developers (unless they are setting it to OOM_SCORE_ADJ_MIN to disable oom killing for that task, for example). It's targeted at sysadmins and daemons that partition a machine to run a number of concurrent jobs. It's fine to use memcg, for example, to do such partitioning, but memcg can also cause oom conditions with the cgroup. We want to be able to tell the kernel, through an interface such as this, that one task shouldn't killed because it's expected to use 3G of memory but should be killed when it's using 8G, for example. -- 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>