From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754130AbcGYXU2 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jul 2016 19:20:28 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:49596 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752915AbcGYXUY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jul 2016 19:20:24 -0400
Date: Mon, 25 Jul 2016 16:20:22 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: <cl@linux.com>, <tj@kernel.org>, <mika.j.penttila@gmail.com>,
        <mingo@redhat.com>, <rjw@rjwysocki.net>, <hpa@zytor.com>,
        <yasu.isimatu@gmail.com>, <isimatu.yasuaki@jp.fujitsu.com>,
        <kamezawa.hiroyu@jp.fujitsu.com>, <izumi.taku@jp.fujitsu.com>,
        <gongzhaogang@inspur.com>, <len.brown@intel.com>, <lenb@kernel.org>,
        <tglx@linutronix.de>, <chen.tang@easystack.cn>, <rafael@kernel.org>,
        <x86@kernel.org>, <linux-acpi@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent
Message-Id: <20160725162022.e90e9c6c74a5d147e39e5945@linux-foundation.org>
In-Reply-To: <1469435749-19582-1-git-send-email-douly.fnst@cn.fujitsu.com>
References: <1469435749-19582-1-git-send-email-douly.fnst@cn.fujitsu.com>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang <douly.fnst@cn.fujitsu.com> wrote:

> [Problem]
> 
> cpuid <-> nodeid mapping is firstly established at boot time. And workqueue caches
> the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
> 
> When doing node online/offline, cpuid <-> nodeid mapping is established/destroyed,
> which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
> workqueue does not update wq_numa_possible_cpumask.
> 
> So here is the problem:
> 
> Assume we have the following cpuid <-> nodeid in the beginning:
> 
>   Node | CPU
> ------------------------
> node 0 |  0-14, 60-74
> node 1 | 15-29, 75-89
> node 2 | 30-44, 90-104
> node 3 | 45-59, 105-119
> 
> and we hot-remove node2 and node3, it becomes:
> 
>   Node | CPU
> ------------------------
> node 0 |  0-14, 60-74
> node 1 | 15-29, 75-89
> 
> and we hot-add node4 and node5, it becomes:
> 
>   Node | CPU
> ------------------------
> node 0 |  0-14, 60-74
> node 1 | 15-29, 75-89
> node 4 | 30-59
> node 5 | 90-119
> 
> But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
> 
> When a pool workqueue is initialized, if its cpumask belongs to a node, its
> pool->node will be mapped to that node. And memory used by this workqueue will
> also be allocated on that node.

Plan B is to hunt down and fix up all the workqueue structures at
hotplug-time.  Has that option been evaluated?


Your fix is x86-only and this bug presumably affects other
architectures, yes?  I think a "Plan B" would fix all architectures?


Thirdly, what is the merge path for these patches?  Is an x86
or ACPI maintainer working with you on them?