> On 13-Mar-2020, at 5:05 PM, Vlastimil Babka wrote:
>
> On 3/13/20 12:12 PM, Srikar Dronamraju wrote:
>> * Michael Ellerman [2020-03-13 21:48:06]:
>>
>>> Sachin Sant writes:
> The patch below might work. Sachin can you test this? I tried faking up
> a system with a memoryless node
On 3/13/20 12:12 PM, Srikar Dronamraju wrote:
> * Michael Ellerman [2020-03-13 21:48:06]:
>
>> Sachin Sant writes:
>> >> The patch below might work. Sachin can you test this? I tried faking up
>> >> a system with a memoryless node zero but couldn't get it to even start
>> >> booting.
>> >>
>>
* Michael Ellerman [2020-03-13 21:48:06]:
> Sachin Sant writes:
> >> The patch below might work. Sachin can you test this? I tried faking up
> >> a system with a memoryless node zero but couldn't get it to even start
> >> booting.
> >>
> > The patch did not help. The kernel crashed during
> >
Sachin Sant writes:
>> The patch below might work. Sachin can you test this? I tried faking up
>> a system with a memoryless node zero but couldn't get it to even start
>> booting.
>>
> The patch did not help. The kernel crashed during
> the boot with the same call trace.
>
> BUG_ON() introduced
> The patch below might work. Sachin can you test this? I tried faking up
> a system with a memoryless node zero but couldn't get it to even start
> booting.
>
The patch did not help. The kernel crashed during
the boot with the same call trace.
BUG_ON() introduced with the patch was not
Michal Hocko writes:
> On Thu 27-02-20 19:26:54, Michal Hocko wrote:
>> [Cc ppc maintainers]
> [...]
>> Please have a look at
>> http://lkml.kernel.org/r/52ef4673-7292-4c4c-b459-af583951b...@linux.vnet.ibm.com
>> for the boot log with the debugging patch which tracks set_numa_mem.
>> This seems
On Thu 27-02-20 19:26:54, Michal Hocko wrote:
> [Cc ppc maintainers]
[...]
> Please have a look at
> http://lkml.kernel.org/r/52ef4673-7292-4c4c-b459-af583951b...@linux.vnet.ibm.com
> for the boot log with the debugging patch which tracks set_numa_mem.
> This seems to lead to a crash in the slab
[Cc ppc maintainers]
On Thu 27-02-20 17:16:41, Vlastimil Babka wrote:
> On 2/27/20 5:00 PM, Sachin Sant wrote:
> >
> >
> >> On 27-Feb-2020, at 5:42 PM, Michal Hocko wrote:
> >>
> >> A very good hint indeed. I would do this
> >> diff --git a/include/linux/topology.h b/include/linux/topology.h
>
On 2/27/20 5:00 PM, Sachin Sant wrote:
>
>
>> On 27-Feb-2020, at 5:42 PM, Michal Hocko wrote:
>>
>> A very good hint indeed. I would do this
>> diff --git a/include/linux/topology.h b/include/linux/topology.h
>> index eb2fe6edd73c..d9f1b6737e4d 100644
>> --- a/include/linux/topology.h
>> +++
> On 27-Feb-2020, at 5:42 PM, Michal Hocko wrote:
>
> A very good hint indeed. I would do this
> diff --git a/include/linux/topology.h b/include/linux/topology.h
> index eb2fe6edd73c..d9f1b6737e4d 100644
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -137,6 +137,8 @@
On Wed 26-02-20 23:29:24, Vlastimil Babka wrote:
> On 2/26/20 10:45 PM, Vlastimil Babka wrote:
> >
> >
> > if (node == NUMA_NO_NODE)
> > page = alloc_pages(flags, order);
> > else
> > page = __alloc_pages_node(node, flags, order);
> >
> > So yeah looks like SLUB's kmalloc_node() is
On Wed 26-02-20 22:45:52, Vlastimil Babka wrote:
> On 2/26/20 7:41 PM, Michal Hocko wrote:
> > On Wed 26-02-20 18:25:28, Cristopher Lameter wrote:
> >> On Mon, 24 Feb 2020, Michal Hocko wrote:
> >>
> >>> Hmm, nasty. Is there any reason why kmalloc_node behaves differently
> >>> from the page
On 2/26/20 10:45 PM, Vlastimil Babka wrote:
>
>
> if (node == NUMA_NO_NODE)
> page = alloc_pages(flags, order);
> else
> page = __alloc_pages_node(node, flags, order);
>
> So yeah looks like SLUB's kmalloc_node() is supposed to behave like the
> page allocator's __alloc_pages_node() and
On 2/26/20 7:41 PM, Michal Hocko wrote:
> On Wed 26-02-20 18:25:28, Cristopher Lameter wrote:
>> On Mon, 24 Feb 2020, Michal Hocko wrote:
>>
>>> Hmm, nasty. Is there any reason why kmalloc_node behaves differently
>>> from the page allocator?
>>
>> The page allocator will do the same thing if you
On Wed 26-02-20 12:31:56, David Rientjes wrote:
> On Wed, 26 Feb 2020, Michal Hocko wrote:
>
> > On Wed 26-02-20 18:44:13, Cristopher Lameter wrote:
> > > On Wed, 26 Feb 2020, Michal Hocko wrote:
> > >
> > > > Besides that kmalloc_node shouldn't really have an implicit GFP_THISNODE
> > > >
On Wed 26-02-20 18:44:13, Cristopher Lameter wrote:
> On Wed, 26 Feb 2020, Michal Hocko wrote:
>
> > Besides that kmalloc_node shouldn't really have an implicit GFP_THISNODE
> > semantic right? At least I do not see anything like that documented
> > anywhere.
>
> Kmalloc_node does not support
On Wed, 26 Feb 2020, Michal Hocko wrote:
> Besides that kmalloc_node shouldn't really have an implicit GFP_THISNODE
> semantic right? At least I do not see anything like that documented
> anywhere.
Kmalloc_node does not support memory policies etc. Only kmalloc does.
kmalloc_node is mostly used
On Wed 26-02-20 18:25:28, Cristopher Lameter wrote:
> On Mon, 24 Feb 2020, Michal Hocko wrote:
>
> > Hmm, nasty. Is there any reason why kmalloc_node behaves differently
> > from the page allocator?
>
> The page allocator will do the same thing if you pass GFP_THISNODE and
> insist on allocating
On Mon, 24 Feb 2020, Michal Hocko wrote:
> Hmm, nasty. Is there any reason why kmalloc_node behaves differently
> from the page allocator?
The page allocator will do the same thing if you pass GFP_THISNODE and
insist on allocating memory from a node that does not exist.
> > > A short summary.
On Sat 22-02-20 03:38:11, Cristopher Lameter wrote:
> On Tue, 18 Feb 2020, Michal Hocko wrote:
>
> > Anyway, I do not think it is expected that kmalloc_node just blows up
> > on those nodes. The page allocator simply falls back to the closest
> > node. Something for kmalloc maintainers I believe.
On Tue, 18 Feb 2020, Michal Hocko wrote:
> Anyway, I do not think it is expected that kmalloc_node just blows up
> on those nodes. The page allocator simply falls back to the closest
> node. Something for kmalloc maintainers I believe.
That is the case for an unconstrained allocation.
On Tue 18-02-20 20:41:12, Sachin Sant wrote:
>
> >> Yes, I can recreate the same problem with the patch applied on top of
> >> 5.6.0-rc2.
> >
> > And just to make sure. This was with
> > http://lkml.kernel.org/r/fff0e636-4c36-ed10-281c-8cdb0687c...@virtuozzo.com
> > right?
> >
> Yes, the same
>> Yes, I can recreate the same problem with the patch applied on top of
>> 5.6.0-rc2.
>
> And just to make sure. This was with
> http://lkml.kernel.org/r/fff0e636-4c36-ed10-281c-8cdb0687c...@virtuozzo.com
> right?
>
Yes, the same patch.
> If yes, is it possible that the specific node is
On Tue 18-02-20 19:30:33, Sachin Sant wrote:
>
>
> > On 18-Feb-2020, at 5:25 PM, Michal Hocko wrote:
> >
> > On Tue 18-02-20 17:10:47, Sachin Sant wrote:
> >>
> could you please test your boot with original patch from here:
>
> https://patchwork.kernel.org/patch/11360007/
>
On Tue 18-02-20 17:10:47, Sachin Sant wrote:
>
> >> could you please test your boot with original patch from here:
> >>
> >> https://patchwork.kernel.org/patch/11360007/
> >
> > After you tried the above patch instead of the problem patch,
> > do one more test and apply the below on current
On 18.02.2020 14:38, Sachin Sant wrote:
>
>
>> On 18-Feb-2020, at 4:20 PM, Kirill Tkhai wrote:
>>
>> Hi, Sachin,
>>
>> On 18.02.2020 13:45, Sachin Sant wrote:
>>>
>>> commit a75056fc1e7c
>>> mm/memcontrol.c: allocate shrinker_map on appropriate NUMA node
>>>
>>> I can boot the kernel
>> could you please test your boot with original patch from here:
>>
>> https://patchwork.kernel.org/patch/11360007/
>
> After you tried the above patch instead of the problem patch,
> do one more test and apply the below on current linux-next.
> Please, say which of the patches makes your
> On 18-Feb-2020, at 4:20 PM, Kirill Tkhai wrote:
>
> Hi, Sachin,
>
> On 18.02.2020 13:45, Sachin Sant wrote:
>>
>> commit a75056fc1e7c
>> mm/memcontrol.c: allocate shrinker_map on appropriate NUMA node
>>
>> I can boot the kernel successfully if the patch is reverted.
>
>
> could you
On 18.02.2020 14:01, Kirill Tkhai wrote:
> On 18.02.2020 13:50, Kirill Tkhai wrote:
>> Hi, Sachin,
>>
>> On 18.02.2020 13:45, Sachin Sant wrote:
>>> Todays next fails to boot on a POWER9 PowerVM logical partition
>>> with following trace:
>>>
>>> [8.767660] random: systemd: uninitialized
Hi, Sachin,
On 18.02.2020 13:45, Sachin Sant wrote:
> Todays next fails to boot on a POWER9 PowerVM logical partition
> with following trace:
>
> [8.767660] random: systemd: uninitialized urandom read (16 bytes read)
> [8.768629] BUG: Kernel NULL pointer dereference on read at 0x73b0
On 18.02.2020 13:50, Kirill Tkhai wrote:
> Hi, Sachin,
>
> On 18.02.2020 13:45, Sachin Sant wrote:
>> Todays next fails to boot on a POWER9 PowerVM logical partition
>> with following trace:
>>
>> [8.767660] random: systemd: uninitialized urandom read (16 bytes read)
>> [8.768629] BUG:
31 matches
Mail list logo
