Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1495472

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

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] oom: print nodemask in the oom report
Date 2016-10-04 17:20 +0200
Message-ID <sozFE-4xt-3@gated-at.bofh.it> (permalink)
References <sndQS-7ww-9@gated-at.bofh.it> <soxXc-3fH-17@gated-at.bofh.it> <soyJA-3Tq-17@gated-at.bofh.it> <sozvY-4tV-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] oom: print nodemask in the oom report Michal Hocko <mhocko@kernel.org> - 2016-09-30 23:50 +0200
  Re: [PATCH] oom: print nodemask in the oom report Vlastimil Babka <vbabka@suse.cz> - 2016-10-04 15:30 +0200
    Re: [PATCH] oom: print nodemask in the oom report Michal Hocko <mhocko@kernel.org> - 2016-10-04 16:20 +0200
      Re: [PATCH] oom: print nodemask in the oom report Vlastimil Babka <vbabka@suse.cz> - 2016-10-04 17:10 +0200
        Re: [PATCH] oom: print nodemask in the oom report Michal Hocko <mhocko@kernel.org> - 2016-10-04 17:20 +0200
          Re: [PATCH] oom: print nodemask in the oom report Vlastimil Babka <vbabka@suse.cz> - 2016-10-05 12:00 +0200

csiph-web