On Sun, Apr 13, 2025 at 05:52:08PM -0500, Ira Weiny wrote: > A git tree of this series can be found here: > > https://github.com/weiny2/linux-kernel/tree/dcd-v6-2025-04-13 > > This is now based on 6.15-rc2. >
Extreme necro-bump for this set, but i wonder what folks opinion is on DCD support if we expose a new region control pattern ala: https://lore.kernel.org/linux-cxl/[email protected]/ The major difference would be elimination of sparse-DAX, which i know has been a concern, in favor of a per-region-driver policy on how to manage hot-add/remove events. Things I've discussed with folks in different private contexts sysram usecase: ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/sysram/bind tagged extents arrive and leave as a group, no sparseness extents cannot share a tag unless they arrive together e.g. set(A) & set(B) must have different tags add and expose daxN.M/uuid as the tag for collective management Can decide whether linux wants to support untagged extents cxl_sysram could choose to track and hotplug untagged extents directly without going through DAX. Partial release would be possible on a per-extent granularity in this case. ---- virtio usecase: (making some stuff up here) ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/virtio/bind tags are required and may imply specific VM routing may or may not use DAX under the hood extents may be tracked individually and add/removed individually if using DAX, this implies 1 device per extent. This probably requires a minimum extent size to be reasonable. Does not expose the memory as SysRAM, instead builds new interface to handle memory management message routing to/from the VMM (N_MEMORY_PRIVATE?) ---- devdax usecase (FAMFS?) ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/devdax/bind All sets of extents appear as new DAX devices Tags are exposed via daxN.M/uuid Tags are required otherwise you can't make sense of what that devdax represents --- Begs the question: Do we require tags as a baseline feature for all modes? No tag - no service. Heavily implied: Tags are globally unique (uuid) But I think this resolves a lot of the disparate disagreements on "what to do with tags" and how to manage sparseness - just split the policy into each individual use-case's respective driver. If a sufficiently unique use-case comes along that doesn't fit the existing categories - a new region-driver may be warranted. ~Gregory
