On 8/26/22 1:30 PM, Wei Xu wrote: > On Thu, Aug 25, 2022 at 8:00 PM Aneesh Kumar K V > <aneesh.kumar@xxxxxxxxxxxxx> wrote: >> >> On 8/26/22 7:20 AM, Huang, Ying wrote: >>> "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes: >>> >>>> This patch adds /sys/devices/virtual/memtier/ where all memory tier related >>>> details can be found. All allocated memory types will be listed there as >>>> /sys/devices/virtual/memtier/memtypeN/ >>> >>> Another choice is to make memory types and memory tiers system devices. >>> That is, >>> >>> /sys/devices/system/memory_type/memory_typeN >>> /sys/devices/system/memory_tier/memory_tierN >>> >> >> subsys_system_register() documentation says >> >> * Do not use this interface for anything new, it exists for compatibility >> * with bad ideas only. New subsystems should use plain subsystems; and >> * add the subsystem-wide attributes should be added to the subsystem >> * directory itself and not some create fake root-device placed in >> * /sys/devices/system/<name>. >> >> memtier being a virtual device, I was under the impression that /sys/devices/virtual >> is the recommended place. >> >>> That looks more natural to me. Because we already have "node" and >>> "memory" devices there. Why don't you put memory types and memory tiers >>> there? >>> >>> And, I think we shouldn't put "memory_type" in the "memory_tier" >>> directory. "memory_type" isn't a part of "memory_tier". >>> >> >> I was looking consolidating both memory tier and memory type into the same sysfs subsystem. >> Your recommendation imply we create two subsystem memory_tier and memtype. I was >> trying to avoid that. May be a generic term like "memory_tiering" can help to >> consolidate all tiering related details there? >> > > A generic term "memory_tiering" sounds good to me. > > Given that this will be a user-facing, stable kernel API, I think we'd > better to only add what is most useful for userspace and don't have to > mirror the kernel internal data structures in this interface. > > My understanding is that we haven't fully settled down on how to > customize memory tiers from userspace. So we don't have to show > memory_type yet, which is a kernel data structure at this point. > > The userspace does need to know what are the memory tiers and which > NUMA nodes are included in each memory tier. How about we provide the > "nodelist" interface for each memory tier as in the original proposal? > > The userspace would also like to know which memory tiers/nodes belong > to the top tiers (the promotion targets). We can provide a "toptiers" > or "toptiers_nodelist" interface to report that. > How about also including abstract distance range of a memory tier? That will be useful to derive the hierarchy. > Both should still be useful even if we decide to add memory_type for > memory tier customization. > -aneesh
