Re: [RFC PATCH 0/3] Add Support for Multiple DC Regions

[Ira Weiny <ira.weiny@intel.com>]

Anisa Su wrote:
> On Thu, Dec 04, 2025 at 11:28:40AM -0600, Ira Weiny wrote:
> > anisa.su887@ wrote:
> > > From: Anisa Su <anisa.su@samsung.com>
> > > 
> > > This patchset introduces support for multiple DC regions. It is rebased on top
> > > of the latest branch published to Ira's repository:
> > > https://github.com/weiny2/linux-kernel/tree/dcd-v6-2025-09-23.
> > > We hope it will be useful in the meantime for others and restart some
> > > discussion around how to move DCD forward.
> > 
> > FWIW it seems patch 1/3 and this patch are both bug fixes to the DCD
> > series I last posted.  If so they should be tacked onto that series.
> > 
> > So, you are more that welcome to take over DCD development.
> > 
> > However, I had multiple DC partitions (Regions) supported in previous
> > versions of that series and the community decided that there was no use
> > case for such a device.  Based on this submission it seems that me ripping
> > out the multiple partitions was incorrect.
> >
> > > 
> > > The corresponding NDCTL support can be found on this branch:
> > > https://github.com/anisa-su993/anisa-ndctl/tree/multiple-dc-region-support.
> > > I will reply to this thread with a reference to the thread for the
> > > NDCTL patches once published.
> > > 
> > > Testing:
> > > This patchset was tested on a QEMU VM with the following topology:
> > 
> > Unfortunately none of the details presented in this cover letter really
> > show why the kernel needs this additional complexity.
> > 
> > Can you go into more details on the use cases of multiple partitions?
> > 
> From what I understand, the motivation for DCD as a whole has always been a
> blocker for the entire series. However, this year we've seen multiple vendors
> demo memory pooling/sharing at SC,25[1], as well as the development of a 
> controller that supports "memory pooling and sharing across 
> multiple hosts" from Montage[2].

That is great!  Do we know if they used the patches which have been
submitted?  Do we know if the user interfaces were sufficient?  How will
this memory be presented with the new DAX changes being proposed?

> 
> The flexibility and control provided by multiple partitions is
> an important capability of DCD for enabling composable memory 
> infrastructures. IMO, adding multi-partition support back in from v8 or
> picking up this patchset would strengthen the series.
> 
> Let me know if this proposal sounds fair? Otherwise I can
> separate out the 2 patches that are bug fixes.

After RC1 could you rebase the series and fold the bug fixes in?

Before we get to multiple DCD partitions the interface for DAX devices
needs to be settled.  In the last community call we were discussing a
special famfs dax type I believe.  Has any work been done on that?

For multi-partitions we need some review on the partition (region) names
because you made a change which would be incompatible with the base
series.  But it would be good to get single partitions landed and then
multiple partitions as you have added.

> Also, apologies if these points have already been discussed. I've not been
> following this series for very long, so forgive the ignorance as I try to
> catch up. If you can think of any materials/documentation outside of the
> mailing list or open collab sync notes that would help fill in the gaps,
> please let me know :)

NP this has been a while.  I've been looking for someone to take the
series who is more familiar with the use cases.

I look forward to you posting a new series with the support you feel you
need.

Ira

> 
> Thanks for the feedback,
> Anisa
> 
> [1] https://computeexpresslink.org/event/supercomputing-2025/
> [2] https://www.montage-tech.com/MXC
> 
> > Also, did you consider to use previous versions of my series?  Perhaps v8?
> > 
> > 	https://lore.kernel.org/all/20241210-dcd-type2-upstream-v8-0-812852504400@intel.com/#r
> > 
> > Thanks,
> > Ira
> > 
> > [snip]