Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2451835pxb; Thu, 11 Feb 2021 12:43:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJyA63/52oQwupSw4XtKWdubwZ7Z+MUWzztkM8Eoqc6EmuBh+YNRs/GGmsBC6oOwVULW8RCF X-Received: by 2002:aa7:c901:: with SMTP id b1mr9989585edt.329.1613076210037; Thu, 11 Feb 2021 12:43:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613076210; cv=none; d=google.com; s=arc-20160816; b=S0Q6qsA9ItiyIQpokE1Ux/sYSK59vFogWBrWEUDWrJaQ3pZlOomFC2ZCaymmZVi/zR HZRMIIm80ofxOPD6Lwx33vii2OtcfiB/YfXdTheI344isxbrzqLG952Zzu/iBdstOVa9 tZS3Gw6GkepUcMY/GVjR5kwXBqdyXY6rLB6Ksm3m/8DdEglD60x+28pDdDdbwNQxhJ89 H44B4d+b3w93pYawos6bTWYt3PHb6KJemxRNP0sQwImirA1voTfkqcHjcT2JMxHBJejG JVXNztXljvZzSJCS52FByuzoJsds72WjB02amMDVqLbckeDdQU23yYdQ9wRbuWlmhboV SBZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=o+MkWSBkvC/UMwT/VgZJGycfyB5NFr4bsCioBd7cfA4=; b=xnbioogfc6mWSY77m8rzTEvEgljLO0bdzC0EC5Pkr0xapf0bC2y5yyk5BrQZ9M95r6 hxpQ4zaH/QPqiTjZX19euw+M6h030QxPeYLwiNyuttBVIHerzbm2Nrhi483/29ikEpBz J8YaZ0BVUG8AdgTyotSJN03leWwiqibqv3glmlcJT3/VnjQZPWA6crjaI+87p/y1yymI vnS2ij2+SmaX3SEKjaPNXqIdukgZtOwdDAXkNgwyGPCmFZNXDQcuDt7NE2ejcyyMMHwi e6EgcGgqqttR18IQT2HGfygWBiXfUEq/eDE+8sLm6B0uaJjkoVtfoY2O5HJh/hGqok2L U2yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=coyflfwb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id z92si4844483ede.291.2021.02.11.12.42.40; Thu, 11 Feb 2021 12:43:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=coyflfwb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S230039AbhBKUlj (ORCPT + 99 others); Thu, 11 Feb 2021 15:41:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229918AbhBKUlh (ORCPT ); Thu, 11 Feb 2021 15:41:37 -0500 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E7AFC061786 for ; Thu, 11 Feb 2021 12:40:57 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id g10so8397908eds.2 for ; Thu, 11 Feb 2021 12:40:57 -0800 (PST) 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=o+MkWSBkvC/UMwT/VgZJGycfyB5NFr4bsCioBd7cfA4=; b=coyflfwbCdbsJ3zzo0z6wSKT59iLTCQVdnZtGrbaNG8QIdR39uPo9V6tfCTRydcisL 4k5JGnBJW2bwe/Y98Ay8kKjlpA7C1M7t5HKlvHlD2W0hs4hkrrX9jMaaFPooSlzZaqeb qnbKvbKvtFMP2Gcb2JhAqzQcRwHeCtf4BKRWIpIIHZen8wJEdzLIzoQePkCym3WVdGd/ 8amklPn5Y1DQDOGZ65J3q4g6AmlJfZBY5cUKedCA145v+34ax7wnmlls4kKFRLPdURDS HwZMs0P9MDREJORNNWoZRXavVtngNRUPbTJE6VBjR5mURUsu/qMEf25CUKIaBzJwIfJh 67gQ== 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=o+MkWSBkvC/UMwT/VgZJGycfyB5NFr4bsCioBd7cfA4=; b=lnQAIwp5dfg0Fxpp0SDPC7ITtQCUqA5+dOPom/BsuvzlA8wZyWMIlbEco2LZqkoXXa ten+8XR0K6Xi8kdv1u88in7MBpK8Dd5TDOkEEpk8ksTOUQ04GE3EH+nPLvxfAgdKYiac k40CTOli3MTb8vzcOhPem431DAy8SPYQjuNFiFSS53Gw3Gy1p2XfTkhQewhPBScwF6Uo jUNhiN++tWTK1TnRSjdgvuOIjxphs+nVdqmvEU6Ezm3P4Pgiyt1n51mZ5a6i7Cq+9GxC 3W3yhGr7TUUHPgPi4kzjAfrhFQoBNuo8pCX5SH0xkfU5U1nUqv++J7M+BTbiPHCHMWUQ yEIg== X-Gm-Message-State: AOAM5325r0Ch+z5xoQ5B6OU93wjbla+zmB0Ht2PboIK11hAjUh9PdgP3 G2Fmr2x8Wpp8s2rPk7ZUW+RpoauINg6/9taSg/pJzw== X-Received: by 2002:a05:6402:3585:: with SMTP id y5mr9870835edc.97.1613076055992; Thu, 11 Feb 2021 12:40:55 -0800 (PST) MIME-Version: 1.0 References: <20210210000259.635748-1-ben.widawsky@intel.com> <20210210000259.635748-4-ben.widawsky@intel.com> <20210210181725.00007865@Huawei.com> <20210211101746.00005e8c@Huawei.com> In-Reply-To: <20210211101746.00005e8c@Huawei.com> From: Dan Williams Date: Thu, 11 Feb 2021 12:40:45 -0800 Message-ID: Subject: Re: [PATCH v2 3/8] cxl/mem: Register CXL memX devices To: Jonathan Cameron Cc: Ben Widawsky , linux-cxl@vger.kernel.org, Linux ACPI , Linux Kernel Mailing List , linux-nvdimm , Linux PCI , Bjorn Helgaas , Chris Browy , Christoph Hellwig , David Hildenbrand , David Rientjes , Ira Weiny , Jon Masters , Rafael Wysocki , Randy Dunlap , Vishal Verma , "John Groves (jgroves)" , "Kelley, Sean V" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 11, 2021 at 2:19 AM Jonathan Cameron wrote: > > On Wed, 10 Feb 2021 18:17:25 +0000 > Jonathan Cameron wrote: > > > On Tue, 9 Feb 2021 16:02:54 -0800 > > Ben Widawsky wrote: > > > > > From: Dan Williams > > > > > > Create the /sys/bus/cxl hierarchy to enumerate: > > > > > > * Memory Devices (per-endpoint control devices) > > > > > > * Memory Address Space Devices (platform address ranges with > > > interleaving, performance, and persistence attributes) > > > > > > * Memory Regions (active provisioned memory from an address space device > > > that is in use as System RAM or delegated to libnvdimm as Persistent > > > Memory regions). > > > > > > For now, only the per-endpoint control devices are registered on the > > > 'cxl' bus. However, going forward it will provide a mechanism to > > > coordinate cross-device interleave. > > > > > > Signed-off-by: Dan Williams > > > Signed-off-by: Ben Widawsky > > > > One stray header, and a request for a tiny bit of reordering to > > make it easier to chase through creation and destruction. > > > > Either way with the header move to earlier patch I'm fine with this one. > > > > Reviewed-by: Jonathan Cameron > > Actually thinking more on this, what is the justification for the > complexity + overhead of a percpu_refcount vs a refcount A typical refcount does not have the block and drain semantics of a percpu_ref. I'm planning to circle back and make this a first class facility of the cdev interface borrowing the debugfs approach [1], but for now percpu_ref fits the bill locally. > I don't think this is a high enough performance path for it to matter. > Perhaps I'm missing a usecase where it does? It's less about percpu_ref performance and more about the percpu_ref_tryget_live() facility. [1]: http://lore.kernel.org/r/CAPcyv4jEYPsyh0bhbtKGRbK3bgp=_+=2rjx4X0gLi5-25VvDyg@mail.gmail.com