Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495472
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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