From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9B4BC433EF for ; Thu, 3 Feb 2022 09:41:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347140AbiBCJld (ORCPT ); Thu, 3 Feb 2022 04:41:33 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]:4663 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230206AbiBCJlc (ORCPT ); Thu, 3 Feb 2022 04:41:32 -0500 Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JqDF41lBMz67Sfy; Thu, 3 Feb 2022 17:40:56 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 3 Feb 2022 10:41:30 +0100 Received: from localhost (10.47.78.15) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 3 Feb 2022 09:41:30 +0000 Date: Thu, 3 Feb 2022 09:41:23 +0000 From: Jonathan Cameron To: Dan Williams CC: , Linux PCI , "Linux NVDIMM" Subject: Re: [PATCH v3 31/40] cxl/memdev: Add numa_node attribute Message-ID: <20220203094123.000049e6@Huawei.com> In-Reply-To: References: <164298411792.3018233.7493009997525360044.stgit@dwillia2-desk3.amr.corp.intel.com> <164298428430.3018233.16409089892707993289.stgit@dwillia2-desk3.amr.corp.intel.com> <20220131184126.00002a47@Huawei.com> <20220202094437.00003c03@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.78.15] X-ClientProxiedBy: lhreml731-chm.china.huawei.com (10.201.108.82) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, 2 Feb 2022 07:44:37 -0800 Dan Williams wrote: > On Wed, Feb 2, 2022 at 1:45 AM Jonathan Cameron > wrote: > > > > On Tue, 1 Feb 2022 15:57:10 -0800 > > Dan Williams wrote: > > > > > On Mon, Jan 31, 2022 at 10:41 AM Jonathan Cameron > > > wrote: > > > > > > > > On Sun, 23 Jan 2022 16:31:24 -0800 > > > > Dan Williams wrote: > > > > > > > > > While CXL memory targets will have their own memory target node, > > > > > individual memory devices may be affinitized like other PCI devices. > > > > > Emit that attribute for memdevs. > > > > > > > > > > Signed-off-by: Dan Williams > > > > > > > > Hmm. Is this just duplicating what we can get from > > > > the PCI device? It feels a bit like overkill to have it here > > > > as well. > > > > > > Not all cxl_memdevs are associated with PCI devices. > > > > Platform devices have numa nodes too... > > So what's the harm in having a numa_node attribute local to the memdev? > I'm not really against, it just wanted to raise the question of whether we want these to go further than the granularity at which numa nodes can be assigned. Right now that at platform_device or PCI EP (from ACPI anyway). Sure the value might come from higher up a hierarchy but at least in theory it can be assigned to individual devices. This is pushing that description beyond that point so is worth discussing. > Yes, userspace could carry complications like: > > cat $(readlink -f /sys/bus/cxl/devices/mem0)/../numa_node > > ...but if you take that argument to its extreme, most "numa_node" > attributes in sysfs could be eliminated because userspace can keep > walking up the hierarchy to find the numa_node versus the kernel doing > it on behalf of userspace.