Re: [PATCH] oom: print nodemask in the oom report

From: Vlastimil Babka
Date: Tue Oct 04 2016 - 11:03:03 EST

On 10/04/2016 04:16 PM, Michal Hocko wrote:
On Tue 04-10-16 15:24:53, Vlastimil Babka wrote:
On 09/30/2016 11:41 PM, Michal Hocko wrote:
Fix this by always priting the nodemask. It is either mempolicy mask
(and non-null) or the one defined by the cpusets.

I wonder if it's helpful to print the cpuset one when that's printed
separately, and seeing both pieces of information (nodemask and cpuset)
unmodified might tell us more. Is it to make it easier to deal with NULL
nodemask? Or to make sure the info gets through pr_warn() and not pr_info()?

I am not sure I understand the question. I wanted to print the nodemask
separatelly in the same line with all other allocation request
parameters like order and gfp mask because that is what the page
allocator got (via policy_nodemask). cpusets builds on top - aka applies
__cpuset_zone_allowed on top of the nodemask. So imho it makes sense to
look at the cpuset as an allocation domain while the mempolicy as a
restriction within this domain.

Does that answer your question?

Ah, I wasn't clear. What I questioned is the fallback to cpusets for NULL nodemask:

nodemask_t *nm = (oc->nodemask) ? oc->nodemask : &cpuset_current_mems_allowed;

The new output for
the above oom report would be

PoolThread invoked oom-killer: gfp_mask=0x280da(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=0, order=0, oom_adj=0, oom_score_adj=0

This patch doesn't touch show_mem and the node filtering based on the
cpuset node mask because mempolicy is always a subset of cpusets and
seeing the full cpuset oom context might be helpful for tunning more
specific mempolicies inside cpusets (e.g. when they turn out to be too
restrictive). To prevent from ugly ifdefs the mask is printed even
for !NUMA configurations but this should be OK (a single node will be

Reported-by: Sellami Abdelkader <abdelkader.sellami@xxxxxxx>
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>

Other than that,

Acked-by: Vlastimil Babka <vbabka@xxxxxxx>