From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) (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 1375121A07A80 for ; Thu, 8 Nov 2018 15:36:39 -0800 (PST) Received: by mail-pl1-f196.google.com with SMTP id p6-v6so20370pll.4 for ; Thu, 08 Nov 2018 15:36:39 -0800 (PST) Message-ID: <1541720197.196084.231.camel@acm.org> Subject: Re: [driver-core PATCH v6 2/9] async: Add support for queueing on specific NUMA node From: Bart Van Assche Date: Thu, 08 Nov 2018 15:36:37 -0800 In-Reply-To: <154170041079.12967.13132220574997822111.stgit@ahduyck-desk1.jf.intel.com> References: <154170028986.12967.2108024712555179678.stgit@ahduyck-desk1.jf.intel.com> <154170041079.12967.13132220574997822111.stgit@ahduyck-desk1.jf.intel.com> Mime-Version: 1.0 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: Alexander Duyck , linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org Cc: len.brown@intel.com, linux-pm@vger.kernel.org, rafael@kernel.org, jiangshanlai@gmail.com, linux-nvdimm@lists.01.org, pavel@ucw.cz, zwisler@kernel.org, tj@kernel.org, akpm@linux-foundation.org List-ID: On Thu, 2018-11-08 at 10:06 -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. Reviewed-by: Bart Van Assche _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm