All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	len.brown@intel.com, rafael@kernel.org, linux-pm@vger.kernel.org,
	jiangshanlai@gmail.com, pavel@ucw.cz, zwisler@kernel.org
Subject: Re: [workqueue/driver-core PATCH v2 1/5] workqueue: Provide queue_work_node to queue work near a given NUMA node
Date: Thu, 11 Oct 2018 10:13:03 -0700	[thread overview]
Message-ID: <fa009c68-7b91-d8cc-76b8-07ea896f146e@linux.intel.com> (raw)
In-Reply-To: <20181011170204.GA7257@kroah.com>

On 10/11/2018 10:02 AM, Greg KH wrote:
> On Thu, Oct 11, 2018 at 09:49:59AM -0700, Alexander Duyck wrote:
>>
>>
>> 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@linux.intel.com>
>>>
>>> Acked-by: Tejun Heo <tj@kernel.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.
> 
> As Tejun has acked this, and it affects the driver core, I'll be glad to
> take it.
> 
> thanks,
> 
> greg k-h

Okay. That works. I will drop Tejun and Andrew to the Cc, and include 
you on the To line for the next submission so it is a bit more clear on 
who should be applying this.

Thanks.

- Alex

  reply	other threads:[~2018-10-11 17:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 23:07 [workqueue/driver-core PATCH v2 0/5] Add NUMA aware async_schedule calls Alexander Duyck
2018-10-10 23:07 ` [workqueue/driver-core PATCH v2 1/5] workqueue: Provide queue_work_node to queue work near a given NUMA node Alexander Duyck
2018-10-11 15:04   ` Tejun Heo
2018-10-11 16:49     ` Alexander Duyck
2018-10-11 17:02       ` Greg KH
2018-10-11 17:13         ` Alexander Duyck [this message]
2018-10-10 23:08 ` [workqueue/driver-core PATCH v2 2/5] async: Add support for queueing on specific " Alexander Duyck
2018-10-11 10:47   ` Greg KH
2018-10-11 15:51     ` Alexander Duyck
2018-10-10 23:08 ` [workqueue/driver-core PATCH v2 3/5] driver core: Probe devices asynchronously instead of the driver Alexander Duyck
2018-10-10 23:08 ` [workqueue/driver-core PATCH v2 4/5] driver core: Attach devices on CPU local to device node Alexander Duyck
2018-10-11 10:45   ` Greg KH
2018-10-11 15:50     ` Alexander Duyck
2018-10-10 23:08 ` [workqueue/driver-core PATCH v2 5/5] PM core: Use new async_schedule_dev command Alexander Duyck

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=fa009c68-7b91-d8cc-76b8-07ea896f146e@linux.intel.com \
    --to=alexander.h.duyck@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=tj@kernel.org \
    --cc=zwisler@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.