From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B08CD21164EF2 for ; Sun, 11 Nov 2018 11:53:32 -0800 (PST) Received: by mail-ot1-x342.google.com with SMTP id t5so6174723otk.1 for ; Sun, 11 Nov 2018 11:53:32 -0800 (PST) MIME-Version: 1.0 References: <154170028986.12967.2108024712555179678.stgit@ahduyck-desk1.jf.intel.com> <154170041079.12967.13132220574997822111.stgit@ahduyck-desk1.jf.intel.com> <20181111193208.GB8332@kroah.com> In-Reply-To: <20181111193208.GB8332@kroah.com> From: Dan Williams Date: Sun, 11 Nov 2018 11:53:20 -0800 Message-ID: Subject: Re: [driver-core PATCH v6 2/9] async: Add support for queueing on specific NUMA node List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Greg KH Cc: "Brown, Len" , bvanassche@acm.org, Linux-pm mailing list , linux-nvdimm , jiangshanlai@gmail.com, Linux Kernel Mailing List , Pavel Machek , zwisler@kernel.org, Tejun Heo , alexander.h.duyck@linux.intel.com, Andrew Morton , "Rafael J. Wysocki" List-ID: On Sun, Nov 11, 2018 at 11:32 AM Greg KH wrote: > > On Thu, Nov 08, 2018 at 10:06:50AM -0800, Alexander Duyck wrote: > > Introduce four new variants of the async_schedule_ functions that allow > > scheduling on a specific NUMA node. > > > > The first two functions are async_schedule_near and > > async_schedule_near_domain end up mapping to async_schedule and > > async_schedule_domain, but provide NUMA node specific functionality. They > > replace the original functions which were moved to inline function > > definitions that call the new functions while passing NUMA_NO_NODE. > > > > The second two functions are async_schedule_dev and > > async_schedule_dev_domain which provide NUMA specific functionality when > > passing a device as the data member and that device has a NUMA node other > > than NUMA_NO_NODE. > > > > The main motivation behind this is to address the need to be able to > > schedule device specific init work on specific NUMA nodes in order to > > improve performance of memory initialization. > > > > Signed-off-by: Alexander Duyck > > --- > > No one else from Intel has reviewed/verified this code at all? > > Please take advantages of the resources you have that most people do > not, get reviewes from your coworkers please before you send this out > again, as they can give you valuable help before the community has to > review the code... I tend to be suspicious of code that arrives on the mailing list day-one with a series of company-internal reviewed-by tags. Sometimes there is preliminary work that can be done internally, but I think we should prefer to do review in the open as much as possible where it does not waste community time. Alex and I did reach a general internal consensus to send this out and get community feedback, but I assumed to do the bulk of the review in parallel with everyone else. That said I think it's fine to ask for some other acks before you take a look, but let's do that in the open. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm