On 3/21/26 16:03, Gregory Price wrote: > Replace per-driver memory type list infrastructure with a single > mt_get_memory_type(adist) that deduplicates against the global > default_memory_types list under memory_tier_lock. > > The per-driver lists (mutex + list_head + find/put wrappers) provided > dedup within a single driver, but not across drivers or with the core. > Since the number of distinct adist values is bounded and types on > default_memory_types are never freed anyway, the per-driver cleanup > on module unload was not useful. > > Add MEMTIER_DEFAULT_LOWTIER_ADISTANCE to replace the default DAX > adistance, since it was really used as a standin for all kmem hotplugged > memory. This at least makes the default tier relationship clearer to > other drivers and they can see where to put their memory in relation to > the default lower tier.
Very confusing code. What's the purpose of kref_get/kref_put if "the types on default_memory_types are never freed anyway" ? IIUC, init_node_memory_type() is always called with one of the types obtained through mt_get_memory_type(). And that one always gives us one from the default_memory_types list, no? Why does mt_find_alloc_memory_type() now even consume a list, if there really only is &default_memory_types? Is there even a need to expose the "struct memory_dev_type" to kmem, when all it does is effectively passing a reference to init_node_memory_type() / clear_node_memory_type(). IOW, couldn't init_node_memory_type()/clear_node_memory_type() just consume the "adist", and lookup the memory type itself? All you'd need is some way in the driver to verify that there is a memory type for the given adist, as some kind of prepare step. Alternatively, let init_node_memory_type() return an error to get a clean interface? :) [...] > mapped++; > } > + data->mtype = mtype; > > dev_set_drvdata(dev, data); > > @@ -253,7 +233,7 @@ static void dev_dax_kmem_remove(struct dev_dax *dev_dax) > * for that. This implies this reference will be around > * till next reboot. > */ > - clear_node_memory_type(node, NULL); > + clear_node_memory_type(node, data->mtype); > } Likely clear_node_memory_type() can now be taught to not handle "!memtype" anymore? -- Cheers, David
