[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871szecrl5.fsf@concordia.ellerman.id.au>
Date: Tue, 18 Oct 2016 13:35:02 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Balbir Singh <bsingharora@...il.com>, Tejun Heo <tj@...nel.org>
Cc: torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
jiangshanlai@...il.com, akpm@...ux-foundation.org,
kernel-team@...com,
"linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)
Balbir Singh <bsingharora@...il.com> writes:
> On 17/10/16 23:24, Michael Ellerman wrote:
>> That happened because we haven't yet called set_cpu_numa_node() for the non-boot
>> cpus, because that happens in smp_prepare_cpus(), and
>> workqueue_init_early() is called much earlier than that.
>>
>> This doesn't trigger on x86 because it does set_cpu_numa_node() in
>> setup_per_cpu_areas(), which is called prior to workqueue_init_early().
>>
>> We can (should) probably do the same on powerpc, I'll look at that
>> tomorrow. But other arches may have a similar problem, and at the very
>> least we need to document that workqueue_init_early() relies on
>> cpu_to_node() working.
>
> Don't we do the setup cpu->node mapings in initmem_init()?
> Ideally we have setup_arch->intmem_init->numa_setup_cpu
That sets up numa_cpu_lookup_table, which is a powerpc only data
structure.
But it doesn't setup the percpu numa_node variables, used by
cpu_to_node(), because percpu areas are not setup yet.
cheers
Powered by blists - more mailing lists