On 11/24/2018 02:43 AM, Dan Williams wrote: > On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> >> On 11/22/18 10:42 PM, Anshuman Khandual wrote: >>> Are we willing to go in the direction for inclusion of a new system >>> call, subset of it appears on sysfs etc ? My primary concern is not >>> how the attribute information appears on the sysfs but lack of it's >>> completeness. >> >> A new system call makes total sense to me. I have the same concern >> about the completeness of what's exposed in sysfs, I just don't see a >> _route_ to completeness with sysfs itself. Thus, the minimalist >> approach as a first step. > > Outside of platform-firmware-id to Linux-numa-node-id what other > userspace API infrastructure does the kernel need to provide? It seems > userspace enumeration of memory attributes is fully enabled once the > firmware-to-Linux identification is established. Which is true if the user space is required to probe the memory attribute values for the platform-firmware-id from the platform and then request required memory from corresponding Linux-numa-node-id via standard mm interfaces like mbind(). But in this patch series we are not mapping platform-firmware-id to Linux-numa-node-id. We are exporting properties applicable to Linux nodes (Linux-numa-node-id). Even if platform-firmware-id to Linux-numa-node-id is required it can be done through a new file like the following. Applications can just take the platform_id node and query platform about it's properties. /sys/devices/system/node/nodeX/platform_id This above interface would have been okay as its just an extension of the existing node information on sysfs. But thats not the case with this proposal.
