Re: [v6 3/4] mm, oom: introduce oom_priority for memory cgroups
From: Michal Hocko <mhocko@kernel.org>
Date: 2017-08-24 12:10:59
Also in:
linux-mm, lkml
On Wed 23-08-17 17:52:00, Roman Gushchin wrote:
Introduce a per-memory-cgroup oom_priority setting: an integer number within the [-10000, 10000] range, which defines the order in which the OOM killer selects victim memory cgroups.
Why do we need a range here?
OOM killer prefers memory cgroups with larger priority if they are populated with eligible tasks.
So this is basically orthogonal to the score based selection and the real size is only the tiebreaker for same priorities? Could you describe the usecase? Becasuse to me this sounds like a separate oom killer strategy. I can imagine somebody might be interested (e.g. always kill the oldest memcgs...) but an explicit range wouldn't fly with such a usecase very well. That brings me back to my original suggestion. Wouldn't a "register an oom strategy" approach much better than blending things together and then have to wrap heads around different combinations of tunables? [...]
quoted hunk ↗ jump to hunk
@@ -2760,7 +2761,12 @@ static void select_victim_memcg(struct mem_cgroup *root, struct oom_control *oc) if (iter->oom_score == 0) continue; - if (iter->oom_score > score) { + if (iter->oom_priority > prio) { + memcg = iter; + prio = iter->oom_priority; + score = iter->oom_score; + } else if (iter->oom_priority == prio && + iter->oom_score > score) { memcg = iter; score = iter->oom_score; }
Just a minor thing. Why do we even have to calculate oom_score when we use it only as a tiebreaker? -- Michal Hocko SUSE Labs