All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Anisa Su <anisa.su887@gmail.com>
Cc: dan.j.williams@intel.com, Ira Weiny <ira.weiny@intel.com>,
	dave@stgolabs.net, linux-cxl@vger.kernel.org,
	nifan.cxl@gmail.com, dongjoo.seo1@samsung.com
Subject: Re: [RFC PATCH 0/3] Add Support for Multiple DC Regions
Date: Mon, 12 Jan 2026 19:08:40 -0500	[thread overview]
Message-ID: <aWWNCDtltJZ3apM8@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aWV6mZYxGdpGnkWJ@4470NRD-ASU.ssi.samsung.com>

On Mon, Jan 12, 2026 at 02:50:01PM -0800, Anisa Su wrote:
> On Sat, Dec 13, 2025 at 12:36:24PM +0900, dan.j.williams@intel.com wrote:
> > Anisa Su wrote:
> > [..]
> > > > 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].
> > > 
> > > 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.
> > 
> > Can you explain the use case for multiple partitions per-device?
> > Describe it in terms of what Linux loses if it never entertains this
> > aspect of the specification. It significantly complicates the ABI for a
> > benefit to Linux that I am unable to articulate.
> 
> Let me backtrack a bit here :( I was too hasty trying to push for
> multiple partitions.
> 
> However, can I ask for some clarification on what a sufficient use case is
> (with just a single partition)?
> 
> Then I'll (try my best) to demonstrate how this series can accomplish it
> so I can help land the single partition stuff first. Does that sound fair
> to you? Or am I misunderstanding the core problem?
> 
> Thanks,
> Anisa

regions != partitions

the discussion from today was regarding FAMFS wanting to balance over
subscription and max bandwidth - which requires a per-device region
and an interleaved regions, they cannot be managed with one region.

I can't think of a reason to need multiple *physical partitions* on
the device, when you can chop up a single partition with many regions.

Either way you need dedicated decoders for each region - regardless of
what partition it's on, so the extra partition doesn't get you much.

~Gregory

      reply	other threads:[~2026-01-13  0:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03 20:29 [RFC PATCH 0/3] Add Support for Multiple DC Regions anisa.su887
2025-12-03 20:29 ` [RFC PATCH 1/3] core/region: fix return logic for store_targetN anisa.su887
2025-12-04 17:04   ` Ira Weiny
2025-12-03 20:29 ` [RFC PATCH 2/3] dax/cxl: add existing dc extents when probing dax region anisa.su887
2025-12-03 21:03   ` Anisa Su
2025-12-04 17:29   ` Ira Weiny
2025-12-03 20:29 ` [RFC PATCH 3/3] dcd: Add support for multiple DC regions anisa.su887
2025-12-04 17:44   ` Ira Weiny
2025-12-03 21:19 ` [RFC PATCH 0/3] Add Support for Multiple DC Regions Anisa Su
2025-12-04 17:28 ` Ira Weiny
2025-12-11 21:05   ` Anisa Su
2025-12-12 22:07     ` Ira Weiny
2026-01-12 22:23       ` Anisa Su
2026-01-15 10:28         ` Alireza Sanaee
2026-02-11  1:44           ` Anisa Su
2026-02-11  9:34             ` Alireza Sanaee
2025-12-13  3:36     ` dan.j.williams
2026-01-12 22:50       ` Anisa Su
2026-01-13  0:08         ` Gregory Price [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWWNCDtltJZ3apM8@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=anisa.su887@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave@stgolabs.net \
    --cc=dongjoo.seo1@samsung.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=nifan.cxl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.