lkml.org 
[lkml]   [2017]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs
Hello, Michael.

On Wed, Aug 23, 2017 at 09:00:39PM +1000, Michael Ellerman wrote:
> > I don't think that's true. The CPU id used in kernel doesn't have to
> > match the physical one and arch code should be able to pre-map CPU IDs
> > to nodes and use the matching one when hotplugging CPUs. I'm not
> > saying that's the best way to solve the problem tho.
>
> We already virtualise the CPU numbers, but not the node IDs. And it's
> the node IDs that are really the problem.

Yeah, it just needs to match up new cpus to the cpu ids assigned to
the right node.

> > It could be that the best way forward is making cpu <-> node mapping
> > dynamic and properly synchronized.
>
> We don't need it to be dynamic (at least for this bug).

The node mapping for that cpu id changes *dynamically* while the
system is running and that can race with node-affinity sensitive
operations such as memory allocations.

> Laurent is booting Qemu with a fixed CPU <-> Node mapping, it's just
> that because some CPUs aren't present at boot we don't know what the
> node mapping is. (Correct me if I'm wrong Laurent).
>
> So all we need is:
> - the workqueue code to cope with CPUs that are possible but not online
> having NUMA_NO_NODE to begin with.
> - a way to update the workqueue cpumask when the CPU comes online.
>
> Which seems reasonable to me?

Please take a step back and think through the problem again. You
can't bandaid it this way.

Thanks.

--
tejun

\
 
 \ /
  Last update: 2017-08-23 15:27    [W:0.304 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site