Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp100719imm; Thu, 20 Sep 2018 16:00:58 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYrm0H/nzH0bbTXO5lhPtgv1IbNaNU409w6WDvMhfzqL5fCti5ceod72eQEoIaX7j65vox9 X-Received: by 2002:a63:2fc6:: with SMTP id v189-v6mr38743336pgv.61.1537484458189; Thu, 20 Sep 2018 16:00:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537484458; cv=none; d=google.com; s=arc-20160816; b=Q/AzcBny6OqJ2h4y6I9XIV1e87mPos7iuZrnRQVXtQzhCuab9IbNslKwlHrNG0w5Fm THpY3eW3ie/TYHxhTb9O5YZBS/ZZU0D9R6D+MQfr9dMtJlNHlUWXXfuEa9I+RdBnbuya 3MQowpGqYo5P5XNB02hw92PYG4yRk3GKtmwSN3QnAT6zWW8307cuupTlyiYx7lNzeIrt qfPEY+lnrCqWZTy5QGa0cGMpPEbx3j4aAvtT3/qQ2/1RIwXqjoRfSyptC2onHYOF6XSR /A6K/9e10cVVRr4tg5EmSTOMPUZCy1gN8yoyuJk/F8M1+YnrmzEWLZCk56rXMuBjtooL gU9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8kEVg4AfF+ri/1ag9LL/dsQqlcNAWtcz0lxcG+tsols=; b=MjpoLMfAqEBua4ChgRpC184mhWyQRPB0acuLHbGGNK9E8l8L2hm8MgEWMFKCXDhplG tBbtap740fThiZQlVqbVnwbW6qZUZ7so04Z5+iPvqCqkt0vlmUHVcDuv6QCRiNmspbRa CbqE8x8s3QTOMHcV85FeoqG4bVEdGX8iawYaXmHRix/uXWBiqhNWXdrx1ETiSwnsOqxM CpiwQ5eTvAJtTe+/09FZ/lNJFlecmjgYeXR/IX9vK7siWCRdNJoYjE44frO11LTxb1NA AzfSqTqi8Fre6Ff1z5vXHFLbn7qIzmKl4j2NIxzlMpF+JT3Gkl3ZdsEPwjlJbhbLnTKB S4PA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=IEYgHn87; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u76-v6si29139014pfj.58.2018.09.20.16.00.41; Thu, 20 Sep 2018 16:00:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=IEYgHn87; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388733AbeIUEpg (ORCPT + 99 others); Fri, 21 Sep 2018 00:45:36 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:36149 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727247AbeIUEpg (ORCPT ); Fri, 21 Sep 2018 00:45:36 -0400 Received: by mail-ot1-f67.google.com with SMTP id w17-v6so11190249otk.3 for ; Thu, 20 Sep 2018 15:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8kEVg4AfF+ri/1ag9LL/dsQqlcNAWtcz0lxcG+tsols=; b=IEYgHn87JPHz2nLAHlDvx5WFxmZojpXDb9K/pa5K+PTjWe+h9ZIwlD47olcKsfdbMQ YyNHw4ZRsF3WEQ5tb2AUcQjiSpcimhwFXX9SJ4t6sQvsnLLDiKGOZLfJd8l14w8LP7ht IpvNDrdvWu1FDYZAwJGOugdmlkLxKm8C7hclHRUvKAQUdOYd3hYx2fdqVLzxI610vqQu Dk+ClNkVHRcw8QeuGHioW/vvg1HvHuWv4pFyFe2g/LCY41kqAdTm+/fK/ZN8l4bWkFct 2L3NS32lc1d11TX2kMmqTVmVcodQxwI5DxY9wGH1Vbxbaso9zCBDNH2Wdw7h9gaZpIny Q3jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8kEVg4AfF+ri/1ag9LL/dsQqlcNAWtcz0lxcG+tsols=; b=ImKB3Wsgp2h7OHSF95Jv+WRDoLFTaAbpyd/+U0vb9iSZ1SJrZ0Nq9zN4bN20Hj8Kah PmJL2Mni9LYq9ul8iTVae6gJ2h/zlEVCKeULZ3JtJAPDHcskqMTjmGUyVn0iTMDOTcGA PHNU4sSyHL9Nyl+nHgFwoRk4EQUj2MyouIa+OkWuuloF/0IgomfCE26M/tt333f7JqUd OBAPRVks8ReQFh1HAA/kmQjkzLdF4sGMAzlQZnYj57geNGbyd/LrmLXM3k0M/xAuDtVK HDukSeY9+myR0AJsjYmsze5t20c5TWzLFVEkndmYoD+E8jk9A3763QV8uttIXKebOUdt 89ug== X-Gm-Message-State: APzg51B/pj90NTugzBAG6KYahqVqt6663StxogT6mvbwZZn74/uB/Hyd tboXVh2NYAfeE7UAuGMT/1rX8Wowr37ZKEOoYPQ0MA== X-Received: by 2002:a9d:50ac:: with SMTP id b44-v6mr24540445oth.267.1537484385582; Thu, 20 Sep 2018 15:59:45 -0700 (PDT) MIME-Version: 1.0 References: <20180920215824.19464.8884.stgit@localhost.localdomain> <20180920222951.19464.39241.stgit@localhost.localdomain> In-Reply-To: <20180920222951.19464.39241.stgit@localhost.localdomain> From: Dan Williams Date: Thu, 20 Sep 2018 15:59:34 -0700 Message-ID: Subject: Re: [PATCH v4 5/5] nvdimm: Schedule device registration on node local to the device To: alexander.h.duyck@linux.intel.com Cc: Linux MM , Linux Kernel Mailing List , linux-nvdimm , Pasha Tatashin , Michal Hocko , Dave Jiang , Ingo Molnar , Dave Hansen , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , Logan Gunthorpe , "Kirill A. Shutemov" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 20, 2018 at 3:31 PM Alexander Duyck wrote: > > This patch is meant to force the device registration for nvdimm devices to > be closer to the actual device. This is achieved by using either the NUMA > node ID of the region, or of the parent. By doing this we can have > everything above the region based on the region, and everything below the > region based on the nvdimm bus. > > One additional change I made is that we hold onto a reference to the parent > while we are going through registration. By doing this we can guarantee we > can complete the registration before we have the parent device removed. > > By guaranteeing NUMA locality I see an improvement of as high as 25% for > per-node init of a system with 12TB of persistent memory. > > Signed-off-by: Alexander Duyck > --- > drivers/nvdimm/bus.c | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c > index 8aae6dcc839f..ca935296d55e 100644 > --- a/drivers/nvdimm/bus.c > +++ b/drivers/nvdimm/bus.c > @@ -487,7 +487,9 @@ static void nd_async_device_register(void *d, async_cookie_t cookie) > dev_err(dev, "%s: failed\n", __func__); > put_device(dev); > } > + > put_device(dev); > + put_device(dev->parent); Good catch. The child does not pin the parent until registration, but we need to make sure the parent isn't gone while were waiting for the registration work to run. Let's break this reference count fix out into its own separate patch, because this looks to be covering a gap that may need to be recommended for -stable. > > static void nd_async_device_unregister(void *d, async_cookie_t cookie) > @@ -504,12 +506,25 @@ static void nd_async_device_unregister(void *d, async_cookie_t cookie) > > void __nd_device_register(struct device *dev) > { > + int node; > + > if (!dev) > return; > + > dev->bus = &nvdimm_bus_type; > + get_device(dev->parent); > get_device(dev); > - async_schedule_domain(nd_async_device_register, dev, > - &nd_async_domain); > + > + /* > + * For a region we can break away from the parent node, > + * otherwise for all other devices we just inherit the node from > + * the parent. > + */ > + node = is_nd_region(dev) ? to_nd_region(dev)->numa_node : > + dev_to_node(dev->parent); Devices already automatically inherit the node of their parent, so I'm not understanding why this is needed?