On Wed, 2 Feb 2022 07:44:37 -0800 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Wed, Feb 2, 2022 at 1:45 AM Jonathan Cameron > <Jonathan.Cameron@xxxxxxxxxx> wrote: > > > > On Tue, 1 Feb 2022 15:57:10 -0800 > > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > > On Mon, Jan 31, 2022 at 10:41 AM Jonathan Cameron > > > <Jonathan.Cameron@xxxxxxxxxx> wrote: > > > > > > > > On Sun, 23 Jan 2022 16:31:24 -0800 > > > > Dan Williams <dan.j.williams@xxxxxxxxx> 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 <dan.j.williams@xxxxxxxxx> > > > > > > > > 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.
