Messages in this thread |  | | Subject | Re: [PATCH] oom: print nodemask in the oom report | From | Vlastimil Babka <> | Date | Tue, 4 Oct 2016 17:02:42 +0200 |
| |
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 >>> printed). >>> >>> Reported-by: Sellami Abdelkader <abdelkader.sellami@sap.com> >>> Signed-off-by: Michal Hocko <mhocko@suse.com> >> >> Other than that, >> >> Acked-by: Vlastimil Babka <vbabka@suse.cz> > > Thanks! >
|  |