Re: [RFC PATCH] x86, numa: always initialize all possible nodes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Michal Hocko <mhocko@xxxxxxxxxx>, linux-mm@xxxxxxxxx
- Subject: Re: [RFC PATCH] x86, numa: always initialize all possible nodes
- From: Dave Hansen <dave.hansen@xxxxxxxxx>
- Date: Thu, 24 Jan 2019 11:10:50 -0800
- Cc: Pingfan Liu <kernelfans@xxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, x86@xxxxxxxxxx, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>, Michael Ellerman <mpe@xxxxxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, linuxppc-dev@xxxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>
- In-reply-to: <20190124141727.GN4087@dhcp22.suse.cz>
- Openpgp: preference=signencrypt
- References: <20190114082416.30939-1-mhocko@kernel.org> <20190124141727.GN4087@dhcp22.suse.cz>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
On 1/24/19 6:17 AM, Michal Hocko wrote:
> and nr_cpus set to 4. The underlying reason is tha the device is bound
> to node 2 which doesn't have any memory and init_cpu_to_node only
> initializes memory-less nodes for possible cpus which nr_cpus restrics.
> This in turn means that proper zonelists are not allocated and the page
> allocator blows up.
This looks OK to me.
Could we add a few DEBUG_VM checks that *look* for these invalid
zonelists? Or, would our existing list debugging have caught this?
Basically, is this bug also a sign that we need better debugging around
this?
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]
