From: Michael Ellerman <mpe@ellerman.id.au>
To: Tejun Heo <tj@kernel.org>, Laurent Vivier <lvivier@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Jens Axboe <axboe@kernel.dk>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs
Date: Tue, 22 Aug 2017 11:41:41 +1000 [thread overview]
Message-ID: <87r2w4bcq2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20170821144832.GE491396@devbig577.frc2.facebook.com>
Tejun Heo <tj@kernel.org> writes:
> On Mon, Aug 21, 2017 at 03:49:50PM +0200, Laurent Vivier wrote:
>> In wq_numa_init() a list of NUMA nodes with their list of possible CPUs
>> is built.
>>
>> Unfortunately, on powerpc, the Firmware is only able to provide the
>> node of a CPU if the CPU is present. So, in our case (possible CPU)
>> CPU ids are known, but as the CPU is not present, the node id is
>> unknown and all the unplugged CPUs are attached to node 0.
>
> This is something powerpc needs to fix.
There is no way for us to fix it.
At boot, for possible but not present CPUs, we have no way of knowing
the CPU <-> node mapping, firmware simply doesn't tell us.
> Workqueue isn't the only one making this assumption. mm as a whole
> assumes that CPU <-> node mapping is stable regardless of hotplug
> events.
At least in this case I don't think the mapping changes, it's just we
don't know the mapping at boot.
Currently we have to report possible but not present CPUs as belonging
to node 0, because otherwise we trip this helpful piece of code:
for_each_possible_cpu(cpu) {
node = cpu_to_node(cpu);
if (WARN_ON(node == NUMA_NO_NODE)) {
pr_warn("workqueue: NUMA node mapping not available for cpu%d, disabling NUMA support\n", cpu);
/* happens iff arch is bonkers, let's just proceed */
return;
}
But if we remove that, we could then accurately report NUMA_NO_NODE at
boot, and then update the mapping when the CPU is hotplugged.
cheers
next prev parent reply other threads:[~2017-08-22 1:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 13:49 [PATCH 1/2] powerpc/workqueue: update list of possible CPUs Laurent Vivier
2017-08-21 13:49 ` [PATCH 2/2] blk-mq: don't use WORK_CPU_UNBOUND Laurent Vivier
2017-08-21 14:48 ` Tejun Heo
2017-08-21 14:48 ` [PATCH 1/2] powerpc/workqueue: update list of possible CPUs Tejun Heo
2017-08-22 1:41 ` Michael Ellerman [this message]
2017-08-22 16:54 ` Tejun Heo
2017-08-23 11:00 ` Michael Ellerman
2017-08-23 11:17 ` Laurent Vivier
2017-08-23 13:26 ` Tejun Heo
2017-08-24 12:10 ` Laurent Vivier
2017-08-24 13:51 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2w4bcq2.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=axboe@kernel.dk \
--cc=jiangshanlai@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lvivier@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox