On Wed, 2017-05-03 at 19:01 -0700, Dan Williams wrote: > On Wed, May 3, 2017 at 4:36 PM, Kani, Toshimitsu <[email protected]> > wrote: > > On Wed, 2017-05-03 at 17:25 -0600, Toshi Kani wrote: > > > On Wed, 2017-05-03 at 16:08 -0700, Dan Williams wrote: > > > > On Wed, May 3, 2017 at 3:51 PM, Dan Williams > > > > <[email protected]> wrote: > > > > > On Wed, May 3, 2017 at 3:41 PM, Kani, Toshimitsu > > > > > <[email protected]> wrote: > > > > > > On Wed, 2017-05-03 at 14:48 -0700, Dan Williams wrote: > > > > > > : > > > > > > > > > > I believe we already have all the data needed to calculate > > > > > the data offset. Given the following sysfs path: > > > > > > > > > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/r > > > > > egion1/dax1.1/dax/dax1.0 > > > > > > > > > > ...we can find the associated namespace device from that > > > > > dax1.1. > > > > > From there we have the base address of the namespace and the > > > > > size device-dax instance. > > > > > > > > > > device_dax_data_offset == namespace_base + namespace_size > > > > > - > > > > > device_dax_size > > > > > > > > Dave reminds me that we do have the data offset of the device- > > > > dax instance at the libnvdimm level: > > > > > > > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/reg > > > > ion1/dax1.1/resource > > > > > > > > ...in this example, which maps to ndctl_dax_get_resource(). > > > > > > Thanks for the info! I noticed why I did not catch this info > > > before. > > > > > > # ll /dev/dax* > > > crw------- 1 root root 251, 3 May 3 04:28 /dev/dax0.0 > > > > > > # pwd > > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/d > > > ax0.0 > > > > > > # grep . * > > > align:2097152 > > > devtype:nd_dax > > > modalias:nd:t7 > > > mode:none > > > numa_node:0 > > > grep: power: Is a directory > > > grep: resource: No such device or address > > > grep: size: No such device or address > > > grep: subsystem: Is a directory > > > uevent:DEVTYPE=nd_dax > > > uevent:MODALIAS=nd:t7 > > > > > > But I noticed that "resource" and "size" that are under > > > ".../region0/dax0.1" work. Is this intended? > > You mean that region0/dax0.1 and region0/dax0.1/dax/dax0.0 are > functional, but region0/dax0.0 is not? Yes, that is expected the > libnvdimm "struct nd_dax" device is on a different device numbering > scheme than the "struct dev_dax" instance. Depending on load and > namespace reconfiguration order you can expect those names to not > match. The dev_dax instance name is "dax region id"."sub-division > instance"
Oh, I see. You are right. Looks like I can use the symbolic link under "class/dax" to avoid this numbering issue. # ll /sys/class/dax/dax0.0 lrwxrwxrwx 1 root root 0 May 4 02:55 /sys/class/dax/dax0.0 -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax0.1 /dax/dax0.0 > > > > Here is an output from dax0.1 (I removed the size value). Noticed > > that mode is different. > > > > # pwd > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax > > 0.1 > > > > # grep . * > > align:2097152 > > grep: dax: Is a directory > > grep: dax_region: Is a directory > > devtype:nd_dax > > grep: driver: Is a directory > > modalias:nd:t7 > > mode:pmem > > namespace:namespace0.0 > > numa_node:0 > > grep: power: Is a directory > > resource:0x250200000 > > size:(size value) > > grep: subsystem: Is a directory > > uevent:DEVTYPE=nd_dax > > uevent:DRIVER=dax_pmem > > uevent:MODALIAS=nd:t7 > > uuid:8c71811f-260d-4788-8487-db88d829d393 > > The "mode" in this instance is the mode for the struct page > allocation, i.e. whether it is coming from main memory "mem" or the > persistent memory itself "pmem" in this case. Right. I was totally confused by the numbering of these files... Thanks! -Toshi
