On 2020/08/20 23:15, Michal Hocko wrote: > I would tend to agree that from the userspace POV it is nice to look at > oom tuning per process but fundamentaly the oom killer operates on the > address space much more than other resources bound to a process because > it is usually the address space hogging the largest portion of the > memory footprint. This is the reason why the oom killer has been > evaluating tasks based on that aspect rather than other potential memory > consumers bound to a task. Mostly due to lack of means to evaluate > those. We already allow specifying potential memory consumers via oom_task_origin(). If we change from a property of the task/thread-group to a property of mm, we won't be able to add means to adjust oom score based on other potential memory consumers bound to a task (e.g. pipes) in the future.
