On Tue, Nov 12, 2019 at 10:02 PM Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > On 11/13/19 6:56 AM, Dan Williams wrote: > > On Tue, Nov 12, 2019 at 1:23 AM Aneesh Kumar K.V > > <aneesh.kumar@xxxxxxxxxxxxx> wrote: > >> > >> Dan Williams <dan.j.williams@xxxxxxxxx> writes: > >> > >>> A 'struct device_type' instance can carry default attributes for the > >>> device. Use this facility to remove the export of > >>> nd_numa_attribute_group and put the responsibility on the core rather > >>> than leaf implementations to define this attribute. > >>> > >>> Cc: Ira Weiny <ira.weiny@xxxxxxxxx> > >>> Cc: Michael Ellerman <mpe@xxxxxxxxxxxxxx> > >>> Cc: "Oliver O'Halloran" <oohall@xxxxxxxxx> > >>> Cc: Vishal Verma <vishal.l.verma@xxxxxxxxx> > >>> Cc: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx> > >>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > >> > >> > >> can we also expose target_node in a similar way? This allows application > >> to better understand the node locality of the SCM device. > > > > It is already exported for device-dax instances. See > > DEVICE_ATTR_RO(target_node) in drivers/dax/bus.c. I did not see a use > > case for it to be exported for other nvdimm device types. > > > > some applications do want to access the fsdax namspace as different > mount points based on numa affinity. If can differentiate the two > regions with different target_node and same numa_node, that will help > them better isolate these mounts. Can you be more explicit than "some", and what's the impact if the kernel continues with the status quo and does not export this data? I'm trying to come up with the justification to include into the changelog that adds that information. At least on the pmem platforms I am working with the pmem ranges with different target nodes also appear on different numa nodes so there is no incremental benefit for target node there.
