linux-kernel - Re: [workqueue/driver-core PATCH v2 1/5] workqueue: Provide queue_work_node to queue work near a given NUMA node

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: <6f91e26d-00e5-10ba-b0ee-2b9f8d50934b@linux.intel.com>
Date:   Thu, 11 Oct 2018 09:49:59 -0700
From:   Alexander Duyck <alexander.h.duyck@...ux.intel.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, len.brown@...el.com,
        rafael@...nel.org, linux-pm@...r.kernel.org,
        jiangshanlai@...il.com, pavel@....cz, zwisler@...nel.org
Subject: Re: [workqueue/driver-core PATCH v2 1/5] workqueue: Provide
 queue_work_node to queue work near a given NUMA node



On 10/11/2018 8:04 AM, Tejun Heo wrote:
> On Wed, Oct 10, 2018 at 04:07:42PM -0700, Alexander Duyck wrote:
>> This patch provides a new function queue_work_node which is meant to
>> schedule work on a "random" CPU of the requested NUMA node. The main
>> motivation for this is to help assist asynchronous init to better improve
>> boot times for devices that are local to a specific node.
>>
>> For now we just default to the first CPU that is in the intersection of the
>> cpumask of the node and the online cpumask. The only exception is if the
>> CPU is local to the node we will just use the current CPU. This should work
>> for our purposes as we are currently only using this for unbound work so
>> the CPU will be translated to a node anyway instead of being directly used.
>>
>> As we are only using the first CPU to represent the NUMA node for now I am
>> limiting the scope of the function so that it can only be used with unbound
>> workqueues.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
> 
> Acked-by: Tejun Heo <tj@...nel.org>
> 
> Please let me know how you wanna route the patch.
> 
> Thanks.

I would be good with routing the patches through you if that works. I 
had included you, Greg, and Andrew as I wasn't sure how you guys had 
wanted this routed since this affected both the workqueue and device trees.

I'll update the patches to resolve the lack of kerneldoc for the new 
"async_" functions and add some comments to the patch descriptions on 
the gains seen related to some of the specific patches for v3.

Thanks.

- Alex