Messages in this thread | | | Date | Wed, 27 Jan 2010 15:56:09 -0800 (PST) | From | David Rientjes <> | Subject | Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling |
| |
On Wed, 27 Jan 2010, KAMEZAWA Hiroyuki wrote:
> Now, /proc/<pid>/oom_score and /proc/<pid>/oom_adj are used by servers.
Nonsense, there are plenty of userspace applications such as udev that tune their own oom_adj value on their own! oom_adj is used by anyone who wants to define oom killer priority by polarizing the badness heuristic for certain tasks to, for example, always prefer them or completely disable oom killing for them.
> After this patch, badness() returns different value based on given context. > Changing format of them was an idea, but, as David said, using "RSS" values > will show unstable oom_score. So, I didn't modify oom_score (for this time). >
That's a seperate issue: you cannot define the baseline of the heuristic in terms of rss because it does not allow userspace to define when a task has become "rogue", i.e. when it is consuming far more memory than expected, because it is a dynamic value that depends on the state of the VM at the time of oom. That is one of the two most popular reasons for tuning oom_adj, the other aforementioned.
The issue with using lowmem rss for CONSTRAINT_LOWMEM is that it misinterprets oom_adj values given to tasks; users will tune their oom_adj based on global, system-wide ooms (or use /proc/pid/oom_score to reveal the priority) and will never understand how it affects the value of a resident page in lowmem for GFP_DMA allocations.
> To be honest, all my work are for guys who don't tweak oom_adj based on oom_score. > IOW, this is for usual novice people. And I don't wan't to break servers which > depends on oom black magic currently supported. >
Why can't you simply create your own heuristic, seperate from badness(), for CONSTRAINT_LOWMEM? Define the criteria that you see as important in selecting a task in that scenario and then propose it as a seperate function, there is no requirement that we must have a single heuristic that works for all the various oom killer constraints. It would be entirely appropriate to ignore oom_adj in that heuristic, as well, since its not defined for such oom conditions (OOM_DISABLE is already taken care of in the tasklist scan and needs no further support).
| |