linux-kernel - Re: [PATCH 1/2] workqueue: update numa affinity info at node hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54B716A0.5020800@cn.fujitsu.com>
Date:	Thu, 15 Jan 2015 09:23:44 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Ishimatsu, Yasuaki/石松 靖章" 
	<isimatu.yasuaki@...fujitsu.com>,
	Tang Chen <tangchen@...fujitsu.com>,
	"guz.fnst@...fujitsu.com" <guz.fnst@...fujitsu.com>
Subject: Re: [PATCH 1/2] workqueue: update numa affinity info at node hotplug

On 01/14/2015 09:57 PM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Wed, Jan 14, 2015 at 10:47:16AM +0800, Lai Jiangshan wrote:
>>> Even if that involves slightly more code, that's the right thing to do at this point.
>>
>> Right, but in currently, the workqueue will be the only user, and I don't known
>> asking who to do it, so I may keep it in the workqueue.c.
> 
> The problem is that working around this in workqueue effectively hides
> what needs to be actively looked upon and decided.  It curently isn't
> currently defined even when such mappings can change or for which
> cpus?  Are all offline cpus up for grabs or just !present ones?  These
> are questions which can only be answered / determined from NUMA side
> and the sooner we deal with this properly the better.

So the solution_B totally keeps away from this spaghetti.

> 
>>> It'd be
>>> awesome if somebody more familiar with the numa side can chime in and
>>> explain why this mapping change can't be avoided.
>>
>> I'm also looking for someone answer it.
> 
> Exactly, whoever is requiring NUMA node remapping should explain and
> justify that and how the model to handle it can only be determined
> from that.
> 
> Thanks.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/