Messages in this thread |  | | Date | Tue, 4 Oct 2016 17:12:58 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH] oom: print nodemask in the oom report |
| |
On Tue 04-10-16 17:02:42, Vlastimil Babka wrote: > 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;
Well no nodemask means there is no mempolicy so either all nodes can be used or they are restricted by the cpuset. cpuset_current_mems_allowed is node_states[N_MEMORY] if there is no cpuset so I believe we are printing the correct information. An alternative would be either not print anything if there is no nodemask or print node_states[N_MEMORY] regardless the cpusets. The first one is quite ugly while the later might be confusing I guess. -- Michal Hocko SUSE Labs
|  |