CMA allocations are currently unaccounted for by cgroup memory
controllers. As system resources, they should fall under memcg, but CMA
areas partition the available space for different purposes and memcg
doesn't have a good representation for that.

Add a memory_cma_accounting cgroupfs option in preparation for the
following new behavior. Make it disabled by default since it will
account for CMA allocations in memcg which may affect existing systems.

Provide CMA charge/uncharge functions to memcg that introduce a CMA area
specific counter per CMA area. Charges are issued to memcg and to a page
counter for the CMA area used. The allocation's folios are marked with
the cgroup via commit_charge() (once for large folios, per-page for
0-order ones) so they can be later uncharged correctly.

Add the new memcg calls into the cma allocator under __cma_alloc_frozen,
for both cma and hugetlb_cma allocations accounting.

Finally register the per-area usage counters in the cgroupfs. Each CMA
area creates a memory.cma.<area>.{current,max} pair for reporting and
limitation for each area.

Selftests and a vmtest script are added to this series for convenience.
The tests are simple accounting and limit enforcement verification using
the default reserved CMA area (cma=) and hugetlb_cma.

Signed-off-by: Eric Chanudet <echanude@redhat.com>
---
Eric Chanudet (11):
      mm/cma: drop const for struct page on release API
      mm/cma: include linux/cma.h in cma.h
      cgroup: add memory_cma_accounting mount option
      memcg: add cma charge/uncharge functions for area counters
      mm/cma: charge cma allocation to memcg per area counters
      memcg: register per-area usage counters in cgroupfs
      selftests: cgroup: add cma configs for cgroup selftest suite
      selftests: cgroup: add memcg cma tests
      selftests: cgroup: add a vmtest script for memcg
      selftests: cgroup: add memcg hugetlb_cma tests
      selftests: cgroup: amend vmtest-memcg to run the hugetlb cma tests

 Documentation/admin-guide/cgroup-v2.rst         |  35 +++
 include/linux/cgroup-defs.h                     |   5 +
 include/linux/cma.h                             |   4 +-
 include/linux/memcontrol.h                      |  19 ++
 kernel/cgroup/cgroup.c                          |  15 +-
 mm/cma.c                                        |  14 +-
 mm/cma.h                                        |   6 +
 mm/cma_debug.c                                  |   1 -
 mm/cma_sysfs.c                                  |   1 -
 mm/memcontrol.c                                 | 205 ++++++++++++
 tools/testing/selftests/cgroup/.gitignore       |   1 +
 tools/testing/selftests/cgroup/Makefile         |   2 +
 tools/testing/selftests/cgroup/config           |   5 +
 tools/testing/selftests/cgroup/test_cma_memcg.c | 402 ++++++++++++++++++++++++
 tools/testing/selftests/cgroup/vmtest-memcg.sh  | 197 ++++++++++++
 15 files changed, 903 insertions(+), 9 deletions(-)
---
base-commit: 98f21c54f99519329c18e2625b0ea6db14524d09
change-id: 20260706-cma-memcg-regions-696cb5ef7998

Best regards,
-- 
Eric Chanudet <echanude@redhat.com>

On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> CMA allocations are currently unaccounted for by cgroup memory
> controllers. As system resources, they should fall under memcg, but CMA
> areas partition the available space for different purposes and memcg
> doesn't have a good representation for that.

Which CMA usecases are covered by this work? It would be also great to
spend more time describing usecases.
-- 
Michal Hocko
SUSE Labs

On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > CMA allocations are currently unaccounted for by cgroup memory
> > controllers. As system resources, they should fall under memcg, but CMA
> > areas partition the available space for different purposes and memcg
> > doesn't have a good representation for that.
> 
> Which CMA usecases are covered by this work? It would be also great to
> spend more time describing usecases.

We would like to offer some usage guaranties to userspace processes
ending up doing allocations in CMA.

For example, a shared CMA area is described in device-tree for an ARM64
platforms. Userspace components could then, for example, allocate from
it through the dmabuf heap, or a device or framework-specific ioctl for
that matter, to use the buffer with sensors. The dtb may have other CMA
areas described additionally that may or may not be used by that
component. In this context, we would like the ability to limit one of
the userspace component to over-allocate and choke the other(s). memcg
looked like a good fit to achieve this, albeit handling the areas, so a
cgroup has a quota in a given CMA resource.

This trails from an earlier post where we tried doing this using
dmem[1], but I was unable to reconcile the requirement for memcg
accounting[2] since from dmem I didn't have memory objects to charge nor
the guaranty there was one. Given CMA is always system memory, it looked
like a better fit to try something without dmem.

Best,

[1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/
[2] https://lore.kernel.org/all/ahB7pCu_G4vuswc0@linux.dev/

> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Eric Chanudet

On 8/25/26 16:47, Eric Chanudet wrote:
> On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
>> On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
>>> CMA allocations are currently unaccounted for by cgroup memory
>>> controllers. As system resources, they should fall under memcg, but CMA
>>> areas partition the available space for different purposes and memcg
>>> doesn't have a good representation for that.
>>
>> Which CMA usecases are covered by this work? It would be also great to
>> spend more time describing usecases.
> 
> We would like to offer some usage guaranties to userspace processes
> ending up doing allocations in CMA.

How does this e.g., relate to hugetlb allocating from CMA, to then charge to a
hugetlb cgroup?

I always thought of CMA being a low-level allocation mechanism with various
different use cases, and actually the higher-level users should decide how
to/what to charge instead.

-- 
Cheers,

David

On Tue 25-08-26 17:45:56, David Hildenbrand wrote:
> On 8/25/26 16:47, Eric Chanudet wrote:
> > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> >> On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> >>> CMA allocations are currently unaccounted for by cgroup memory
> >>> controllers. As system resources, they should fall under memcg, but CMA
> >>> areas partition the available space for different purposes and memcg
> >>> doesn't have a good representation for that.
> >>
> >> Which CMA usecases are covered by this work? It would be also great to
> >> spend more time describing usecases.
> > 
> > We would like to offer some usage guaranties to userspace processes
> > ending up doing allocations in CMA.
> 
> How does this e.g., relate to hugetlb allocating from CMA, to then charge to a
> hugetlb cgroup?
> 
> I always thought of CMA being a low-level allocation mechanism with various
> different use cases, and actually the higher-level users should decide how
> to/what to charge instead.

Exactly. There are many different users of CMA all with different
requirements. Then there is CMA reservations if an area is shared and
the overall memory consumption. That is why I am really not able to
wrap my head around this proposal.


-- 
Michal Hocko
SUSE Labs

On Tue, Aug 25, 2026 at 06:26:42PM +0200, Michal Hocko wrote:
> On Tue 25-08-26 17:45:56, David Hildenbrand wrote:
> > On 8/25/26 16:47, Eric Chanudet wrote:
> > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > >> On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > >>> CMA allocations are currently unaccounted for by cgroup memory
> > >>> controllers. As system resources, they should fall under memcg, but CMA
> > >>> areas partition the available space for different purposes and memcg
> > >>> doesn't have a good representation for that.
> > >>
> > >> Which CMA usecases are covered by this work? It would be also great to
> > >> spend more time describing usecases.
> > > 
> > > We would like to offer some usage guaranties to userspace processes
> > > ending up doing allocations in CMA.
> > 
> > How does this e.g., relate to hugetlb allocating from CMA, to then charge to a
> > hugetlb cgroup?
> > 

AFAIU the system defines CMA areas to allocate hugepages from. For this
initial series, I failed to handle it. The intend was to consider it as
any other CMA area. It entirely missed that hugepages are already
accounted for by their controller (cgroupfs opt
memory_hugetlb_accounting) and they are charged when faulted in from
their available pool.

> > I always thought of CMA being a low-level allocation mechanism with various
> > different use cases, and actually the higher-level users should decide how
> > to/what to charge instead.
> 
> Exactly. There are many different users of CMA all with different
> requirements. Then there is CMA reservations if an area is shared and
> the overall memory consumption. That is why I am really not able to
> wrap my head around this proposal.

It is nonetheless available almost directly to userspace via dmabuf
heap, or as a result of drivers ioctl providing a contiguous buffer, and
unaccounted for by existing controllers, with the exception of CMA
hugepages with memory_hugetlb_accounting. The dmabuf heap use would have
userspace choose the area(s), but allow for no limit to be applied
beyond that, which is desirable for areas shared by multiple userspace
components.

> 
> 
> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Eric Chanudet

On 8/25/26 20:50, Eric Chanudet wrote:
> On Tue, Aug 25, 2026 at 06:26:42PM +0200, Michal Hocko wrote:
>> On Tue 25-08-26 17:45:56, David Hildenbrand wrote:
>>>
>>> How does this e.g., relate to hugetlb allocating from CMA, to then charge to a
>>> hugetlb cgroup?
>>>
> 
> AFAIU the system defines CMA areas to allocate hugepages from. For this
> initial series, I failed to handle it. The intend was to consider it as
> any other CMA area. It entirely missed that hugepages are already
> accounted for by their controller (cgroupfs opt
> memory_hugetlb_accounting) and they are charged when faulted in from
> their available pool.
> 
>>> I always thought of CMA being a low-level allocation mechanism with various
>>> different use cases, and actually the higher-level users should decide how
>>> to/what to charge instead.
>>
>> Exactly. There are many different users of CMA all with different
>> requirements. Then there is CMA reservations if an area is shared and
>> the overall memory consumption. That is why I am really not able to
>> wrap my head around this proposal.
> 
> It is nonetheless available almost directly to userspace via dmabuf
> heap, or as a result of drivers ioctl providing a contiguous buffer, and
> unaccounted for by existing controllers, with the exception of CMA
> hugepages with memory_hugetlb_accounting.

No. The charging really only makes sense for selected mechanisms that built onto
CMA.

It does not make any sense for subsystems that declare CMA for their own use only.

Like hugetlb. Or s390x's VMCP region. Or PPC KVM stuff. Or the crash kernel area.

-- 
Cheers,

David

On Wed, Aug 26, 2026 at 10:02:08AM +0200, David Hildenbrand (Arm) wrote:
> On 8/25/26 20:50, Eric Chanudet wrote:
> > On Tue, Aug 25, 2026 at 06:26:42PM +0200, Michal Hocko wrote:
> >> On Tue 25-08-26 17:45:56, David Hildenbrand wrote:
> >>>
> >>> How does this e.g., relate to hugetlb allocating from CMA, to then charge to a
> >>> hugetlb cgroup?
> >>>
> > 
> > AFAIU the system defines CMA areas to allocate hugepages from. For this
> > initial series, I failed to handle it. The intend was to consider it as
> > any other CMA area. It entirely missed that hugepages are already
> > accounted for by their controller (cgroupfs opt
> > memory_hugetlb_accounting) and they are charged when faulted in from
> > their available pool.
> > 
> >>> I always thought of CMA being a low-level allocation mechanism with various
> >>> different use cases, and actually the higher-level users should decide how
> >>> to/what to charge instead.
> >>
> >> Exactly. There are many different users of CMA all with different
> >> requirements. Then there is CMA reservations if an area is shared and
> >> the overall memory consumption. That is why I am really not able to
> >> wrap my head around this proposal.
> > 
> > It is nonetheless available almost directly to userspace via dmabuf
> > heap, or as a result of drivers ioctl providing a contiguous buffer, and
> > unaccounted for by existing controllers, with the exception of CMA
> > hugepages with memory_hugetlb_accounting.
> 
> No. The charging really only makes sense for selected mechanisms that built onto
> CMA.
> 
> It does not make any sense for subsystems that declare CMA for their own use only.
> 
> Like hugetlb. Or s390x's VMCP region. Or PPC KVM stuff. Or the crash kernel area.

I see. The crash-kernel does not use the CMA allocator it would not be
affected, VMCP or PPC KVM HPT use specific areas and do not have
userspace use AFAIU. They would default to the root cgroup that does not
get charged. Maybe it should instead be more like GFP_ACCOUNT, making
charging opt-in when the allocation happens on behalf of userspace?

From the other thread it doesn't seem like memcg is a good fit either.

> 
> -- 
> Cheers,
> 
> David
> 

-- 
Eric Chanudet

On Tue 25-08-26 10:47:53, Eric Chanudet wrote:
> On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > > CMA allocations are currently unaccounted for by cgroup memory
> > > controllers. As system resources, they should fall under memcg, but CMA
> > > areas partition the available space for different purposes and memcg
> > > doesn't have a good representation for that.
> > 
> > Which CMA usecases are covered by this work? It would be also great to
> > spend more time describing usecases.
> 
> We would like to offer some usage guaranties to userspace processes
> ending up doing allocations in CMA.
> 
> For example, a shared CMA area is described in device-tree for an ARM64
> platforms. Userspace components could then, for example, allocate from
> it through the dmabuf heap, or a device or framework-specific ioctl for
> that matter, to use the buffer with sensors. The dtb may have other CMA
> areas described additionally that may or may not be used by that
> component. In this context, we would like the ability to limit one of
> the userspace component to over-allocate and choke the other(s).

How exactly is this supposed to work? How is the CMA access controled
and opted in for accounting. What happens when memcg limits are hit. And
many more details, please.

> memcg
> looked like a good fit to achieve this, albeit handling the areas, so a
> cgroup has a quota in a given CMA resource.

Please expand more on why do you think this fits into the memcg model.
AFAIU we are talking about a unreclaimable memory and reservations of
CMA areas.

> This trails from an earlier post where we tried doing this using
> dmem[1], but I was unable to reconcile the requirement for memcg
> accounting[2] since from dmem I didn't have memory objects to charge nor
> the guaranty there was one. Given CMA is always system memory, it looked
> like a better fit to try something without dmem.
> 
> Best,
> 
> [1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/
> [2] https://lore.kernel.org/all/ahB7pCu_G4vuswc0@linux.dev/
> 
> > -- 
> > Michal Hocko
> > SUSE Labs
> > 
> 
> -- 
> Eric Chanudet

-- 
Michal Hocko
SUSE Labs

On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> On Tue 25-08-26 10:47:53, Eric Chanudet wrote:
> > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > > On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > > > CMA allocations are currently unaccounted for by cgroup memory
> > > > controllers. As system resources, they should fall under memcg, but CMA
> > > > areas partition the available space for different purposes and memcg
> > > > doesn't have a good representation for that.
> > > 
> > > Which CMA usecases are covered by this work? It would be also great to
> > > spend more time describing usecases.
> > 
> > We would like to offer some usage guaranties to userspace processes
> > ending up doing allocations in CMA.
> > 
> > For example, a shared CMA area is described in device-tree for an ARM64
> > platforms. Userspace components could then, for example, allocate from
> > it through the dmabuf heap, or a device or framework-specific ioctl for
> > that matter, to use the buffer with sensors. The dtb may have other CMA
> > areas described additionally that may or may not be used by that
> > component. In this context, we would like the ability to limit one of
> > the userspace component to over-allocate and choke the other(s).
> 
> How exactly is this supposed to work? How is the CMA access controled
> and opted in for accounting. What happens when memcg limits are hit. And
> many more details, please.
> 

The administrator opts in by mounting cgroupfs with
memory_cma_accounting. At which point the cma allocator will charge CMA
allocations against memcg and manages a per area counter depending on
what area the allocation was made into.

Assuming memory_cma_accounting is set, if a non-root cgroup makes a CMA
allocation over either memcg's max limit or the per-area limit set by
the admin, the allocation fails with ENOMEM.

If memory_cma_accounting is dynamically unset, no the CMA allocator no
longer issues charges. Whatever was already charged can be uncharged
when it gets released.

It looked consistent to use memcg since movable pages from regular
allocations may end up in available CMA regions until a CMA allocation
needs the space and has them moved. So in an extreme case, hogging the
CMA space of a large enough area could trigger system memory pressure.

> > memcg
> > looked like a good fit to achieve this, albeit handling the areas, so a
> > cgroup has a quota in a given CMA resource.
> 
> Please expand more on why do you think this fits into the memcg model.
> AFAIU we are talking about a unreclaimable memory and reservations of
> CMA areas.

Since memcg already accounts for some unreclaimable memory (kmem,
hugetlb), or induces failure if no reclamation is possible, I did not
see CMA allocations being unreclaimable to be a blocker to track what is
otherwise system memory.

I viewed pages allocated in CMA as guarantying special properties while
being otherwise similar to pages already accounted in memcg to the point
that charging them against memcg made more sense than having an entirely
different pool. I can see how that could be the other way around though,
especially with the per area counters, like how hugetlb have their own
controller.

> > This trails from an earlier post where we tried doing this using
> > dmem[1], but I was unable to reconcile the requirement for memcg
> > accounting[2] since from dmem I didn't have memory objects to charge nor
> > the guaranty there was one. Given CMA is always system memory, it looked
> > like a better fit to try something without dmem.
> > 
> > Best,
> > 
> > [1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/
> > [2] https://lore.kernel.org/all/ahB7pCu_G4vuswc0@linux.dev/
> > 
> > > -- 
> > > Michal Hocko
> > > SUSE Labs
> > > 
> > 
> > -- 
> > Eric Chanudet
> 
> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Eric Chanudet

On Tue 25-08-26 14:33:48, Eric Chanudet wrote:
> On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> > On Tue 25-08-26 10:47:53, Eric Chanudet wrote:
> > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > > > On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > > > > CMA allocations are currently unaccounted for by cgroup memory
> > > > > controllers. As system resources, they should fall under memcg, but CMA
> > > > > areas partition the available space for different purposes and memcg
> > > > > doesn't have a good representation for that.
> > > > 
> > > > Which CMA usecases are covered by this work? It would be also great to
> > > > spend more time describing usecases.
> > > 
> > > We would like to offer some usage guaranties to userspace processes
> > > ending up doing allocations in CMA.
> > > 
> > > For example, a shared CMA area is described in device-tree for an ARM64
> > > platforms. Userspace components could then, for example, allocate from
> > > it through the dmabuf heap, or a device or framework-specific ioctl for
> > > that matter, to use the buffer with sensors. The dtb may have other CMA
> > > areas described additionally that may or may not be used by that
> > > component. In this context, we would like the ability to limit one of
> > > the userspace component to over-allocate and choke the other(s).
> > 
> > How exactly is this supposed to work? How is the CMA access controled
> > and opted in for accounting. What happens when memcg limits are hit. And
> > many more details, please.
> > 
> 
> The administrator opts in by mounting cgroupfs with
> memory_cma_accounting. At which point the cma allocator will charge CMA
> allocations against memcg and manages a per area counter depending on
> what area the allocation was made into.

So each CMA area will have its own counter and limits?
 
> Assuming memory_cma_accounting is set, if a non-root cgroup makes a CMA
> allocation over either memcg's max limit or the per-area limit set by
> the admin, the allocation fails with ENOMEM.

No memory reclaim is triggered?
 
> If memory_cma_accounting is dynamically unset, no the CMA allocator no
> longer issues charges. Whatever was already charged can be uncharged
> when it gets released.

I do not follow

> It looked consistent to use memcg since movable pages from regular
> allocations may end up in available CMA regions until a CMA allocation
> needs the space and has them moved. So in an extreme case, hogging the
> CMA space of a large enough area could trigger system memory pressure.

I really do not understand what you mean here. 

> > > memcg
> > > looked like a good fit to achieve this, albeit handling the areas, so a
> > > cgroup has a quota in a given CMA resource.
> > 
> > Please expand more on why do you think this fits into the memcg model.
> > AFAIU we are talking about a unreclaimable memory and reservations of
> > CMA areas.
> 
> Since memcg already accounts for some unreclaimable memory (kmem,
> hugetlb),

hugetlb pages have their own controller

> or induces failure if no reclamation is possible, I did not
> see CMA allocations being unreclaimable to be a blocker to track what is
> otherwise system memory.

yes, we can have unreclaimable memory charged to memcg, that is not a
real problem. We have all sorts of memory consumers that need to be
capped charged to the memcg. If dmabufs are another ones then fine, just
charge allocated pages from the cma area. It is the "make all cma users
memcg aware and have per cma limits" that I am really struggling with.
You cannot really assume usecase, requirements, lifetime etc. for an
arbitrary cma area. I do not think this is a viable way forward. Focus
on your real usecase, which seems to be dmabufs.

Explain what do you want to achieve and then we can think whether memcg
is the right model for that usecase.
-- 
Michal Hocko
SUSE Labs

On Tue, Aug 25, 2026 at 09:19:21PM +0200, Michal Hocko wrote:
> On Tue 25-08-26 14:33:48, Eric Chanudet wrote:
> > On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> > > On Tue 25-08-26 10:47:53, Eric Chanudet wrote:
> > > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > > > > On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > > > > > CMA allocations are currently unaccounted for by cgroup memory
> > > > > > controllers. As system resources, they should fall under memcg, but CMA
> > > > > > areas partition the available space for different purposes and memcg
> > > > > > doesn't have a good representation for that.
> > > > > 
> > > > > Which CMA usecases are covered by this work? It would be also great to
> > > > > spend more time describing usecases.
> > > > 
> > > > We would like to offer some usage guaranties to userspace processes
> > > > ending up doing allocations in CMA.
> > > > 
> > > > For example, a shared CMA area is described in device-tree for an ARM64
> > > > platforms. Userspace components could then, for example, allocate from
> > > > it through the dmabuf heap, or a device or framework-specific ioctl for
> > > > that matter, to use the buffer with sensors. The dtb may have other CMA
> > > > areas described additionally that may or may not be used by that
> > > > component. In this context, we would like the ability to limit one of
> > > > the userspace component to over-allocate and choke the other(s).
> > > 
> > > How exactly is this supposed to work? How is the CMA access controled
> > > and opted in for accounting. What happens when memcg limits are hit. And
> > > many more details, please.
> > > 
> > 
> > The administrator opts in by mounting cgroupfs with
> > memory_cma_accounting. At which point the cma allocator will charge CMA
> > allocations against memcg and manages a per area counter depending on
> > what area the allocation was made into.
> 
> So each CMA area will have its own counter and limits?

Yes, in order to enforce a limit per CMA area this series add a page
counter for each area. Areas are fixed and discovered early so the
counters are added to struct mem_cgroup and initialized when the cgroup
is created.

An admin would then use the cgroupfs entries to assign an area limit to
a given cgroup, something like the following, using the reserved area
for example:
  mount -o remount,memory_cma_accounting /sys/fs/cgroup
  echo +memory > /sys/fs/cgroup/cgroup.subtree_control
  mkdir /sys/fs/cgroup/mycg
  echo 16M > /sys/fs/cgroup/mycg/memory.cma.reserved.max
  echo 64M > /sys/fs/cgroup/mycg/memory.max

> > Assuming memory_cma_accounting is set, if a non-root cgroup makes a CMA
> > allocation over either memcg's max limit or the per-area limit set by
> > the admin, the allocation fails with ENOMEM.
> 
> No memory reclaim is triggered?

Oh I see, try_charge_memcg() may try to reclaim and would do so before
the area counter is checked. So a dmabuf heap allocation in CMA could
end up with a page cache eviction if the memcg limit is reached by the
allocation. That is down to the configuration setup by the admin, I
didn't put any check that would prevent say
  echo 1M > ..mycg/memory.max
  echo 16M > ..mycg/memory.cma.reserved.max
, which would exacerbate that scenario.

> > If memory_cma_accounting is dynamically unset, no the CMA allocator no
> > longer issues charges. Whatever was already charged can be uncharged
> > when it gets released.
> 
> I do not follow

I mangled my sentence halfway, I'm sorry. I meant that the charges
persist until the resources are released. Enabling memory_cma_accounting
only controls if new charges are issued.

> > It looked consistent to use memcg since movable pages from regular
> > allocations may end up in available CMA regions until a CMA allocation
> > needs the space and has them moved. So in an extreme case, hogging the
> > CMA space of a large enough area could trigger system memory pressure.
> 
> I really do not understand what you mean here. 

Non-CMA allocations can end up in CMA physical regions when necessary
(ALLOC_CMA flag). Since both CMA allocations and other system
allocations are represented the same way, with differences only in
properties, and they can live in the same regions, it sounds reasonable
to account for both under the same counter.

> > > > memcg
> > > > looked like a good fit to achieve this, albeit handling the areas, so a
> > > > cgroup has a quota in a given CMA resource.
> > > 
> > > Please expand more on why do you think this fits into the memcg model.
> > > AFAIU we are talking about a unreclaimable memory and reservations of
> > > CMA areas.
> > 
> > Since memcg already accounts for some unreclaimable memory (kmem,
> > hugetlb),
> 
> hugetlb pages have their own controller
> 
> > or induces failure if no reclamation is possible, I did not
> > see CMA allocations being unreclaimable to be a blocker to track what is
> > otherwise system memory.
> 
> yes, we can have unreclaimable memory charged to memcg, that is not a
> real problem. We have all sorts of memory consumers that need to be
> capped charged to the memcg. If dmabufs are another ones then fine, just
> charge allocated pages from the cma area. It is the "make all cma users
> memcg aware and have per cma limits" that I am really struggling with.

CMA is system memory independently from its usage though, and in cases
with shared CMA areas multiple users can allocate from them. Yet the
kernel cannot enforce usage limits.

> You cannot really assume usecase, requirements, lifetime etc. for an
> arbitrary cma area. I do not think this is a viable way forward. Focus
> on your real usecase, which seems to be dmabufs.

While dmabufs are indeed my main use case, they are quite generic and
may not always have system memory backing them (device memory). Working
at the CMA allocator alleviated these disparities.

> Explain what do you want to achieve and then we can think whether memcg
> is the right model for that usecase

Hopefully I expressed this in a better way by now. In short, enforce
usage limits for concurrent CMA users using shared CMA resources.

> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Eric Chanudet

On Tue 25-08-26 16:58:51, Eric Chanudet wrote:
> On Tue, Aug 25, 2026 at 09:19:21PM +0200, Michal Hocko wrote:
> > On Tue 25-08-26 14:33:48, Eric Chanudet wrote:
> > > On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> > > > On Tue 25-08-26 10:47:53, Eric Chanudet wrote:
> > > > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote:
> > > > > > On Fri 21-08-26 14:56:52, Eric Chanudet wrote:
> > > > > > > CMA allocations are currently unaccounted for by cgroup memory
> > > > > > > controllers. As system resources, they should fall under memcg, but CMA
> > > > > > > areas partition the available space for different purposes and memcg
> > > > > > > doesn't have a good representation for that.
> > > > > > 
> > > > > > Which CMA usecases are covered by this work? It would be also great to
> > > > > > spend more time describing usecases.
> > > > > 
> > > > > We would like to offer some usage guaranties to userspace processes
> > > > > ending up doing allocations in CMA.
> > > > > 
> > > > > For example, a shared CMA area is described in device-tree for an ARM64
> > > > > platforms. Userspace components could then, for example, allocate from
> > > > > it through the dmabuf heap, or a device or framework-specific ioctl for
> > > > > that matter, to use the buffer with sensors. The dtb may have other CMA
> > > > > areas described additionally that may or may not be used by that
> > > > > component. In this context, we would like the ability to limit one of
> > > > > the userspace component to over-allocate and choke the other(s).
> > > > 
> > > > How exactly is this supposed to work? How is the CMA access controled
> > > > and opted in for accounting. What happens when memcg limits are hit. And
> > > > many more details, please.
> > > > 
> > > 
> > > The administrator opts in by mounting cgroupfs with
> > > memory_cma_accounting. At which point the cma allocator will charge CMA
> > > allocations against memcg and manages a per area counter depending on
> > > what area the allocation was made into.
> > 
> > So each CMA area will have its own counter and limits?
> 
> Yes, in order to enforce a limit per CMA area this series add a page
> counter for each area. Areas are fixed and discovered early so the
> counters are added to struct mem_cgroup and initialized when the cgroup
> is created.
> 
> An admin would then use the cgroupfs entries to assign an area limit to
> a given cgroup, something like the following, using the reserved area
> for example:
>   mount -o remount,memory_cma_accounting /sys/fs/cgroup
>   echo +memory > /sys/fs/cgroup/cgroup.subtree_control
>   mkdir /sys/fs/cgroup/mycg
>   echo 16M > /sys/fs/cgroup/mycg/memory.cma.reserved.max
>   echo 64M > /sys/fs/cgroup/mycg/memory.max

OK, thanks for the clarification. This confirms my initial suspicion but
it is better to have it clearly articulated. I can see several problems
with this approach. First and formost I do not think dealing with all
cmas this way is manageable. This can become a mess very quickly if we
have one limit per cma and too coarse if there is a single one. I also
have my doubts about space allocation control through a simple limit for
something that is effectively a reserved physical space.

I might be proven wrong but unless cma serves objects of a uniform
size then this will simply not work in practice. Hitting ENOSPC without
hitting limits and thus impractical for shared space management.

[...]

> > > It looked consistent to use memcg since movable pages from regular
> > > allocations may end up in available CMA regions until a CMA allocation
> > > needs the space and has them moved. So in an extreme case, hogging the
> > > CMA space of a large enough area could trigger system memory pressure.
> > 
> > I really do not understand what you mean here. 
> 
> Non-CMA allocations can end up in CMA physical regions when necessary
> (ALLOC_CMA flag).

Correct. But those are a subject of migration so any such placement
should not be blocking real CMA allocations.

> Since both CMA allocations and other system
> allocations are represented the same way, with differences only in
> properties, and they can live in the same regions, it sounds reasonable
> to account for both under the same counter.

From the memcg POV we do account physically consumed memory. So yes,
it makes no difference where the memory comes from. We only care about
the overall capacity you can constrain or protect. Generally speaking it
makes sense to charge heavy memory consumers directly triggerable from
the userspace.

That is all memcg can provide you with. Specific requirements for
specific types of memory is a different story. We currently cannot
control per-numa node for example. There is an ongoing work to make
memcg memory tier aware. 

> > > > > memcg
> > > > > looked like a good fit to achieve this, albeit handling the areas, so a
> > > > > cgroup has a quota in a given CMA resource.
> > > > 
> > > > Please expand more on why do you think this fits into the memcg model.
> > > > AFAIU we are talking about a unreclaimable memory and reservations of
> > > > CMA areas.
> > > 
> > > Since memcg already accounts for some unreclaimable memory (kmem,
> > > hugetlb),
> > 
> > hugetlb pages have their own controller
> > 
> > > or induces failure if no reclamation is possible, I did not
> > > see CMA allocations being unreclaimable to be a blocker to track what is
> > > otherwise system memory.
> > 
> > yes, we can have unreclaimable memory charged to memcg, that is not a
> > real problem. We have all sorts of memory consumers that need to be
> > capped charged to the memcg. If dmabufs are another ones then fine, just
> > charge allocated pages from the cma area. It is the "make all cma users
> > memcg aware and have per cma limits" that I am really struggling with.
> 
> CMA is system memory independently from its usage though, and in cases
> with shared CMA areas multiple users can allocate from them. Yet the
> kernel cannot enforce usage limits.

Correct. Those are effectively a shared memory pools without any
control. I do not think memcg is a good method to enfore any usage
limits for that though for reasons mentioned above. Memcg is effective
at capping the overall memory consumption of a workload. Not really
great when it comes to a specific memory pool control.

> > You cannot really assume usecase, requirements, lifetime etc. for an
> > arbitrary cma area. I do not think this is a viable way forward. Focus
> > on your real usecase, which seems to be dmabufs.
> 
> While dmabufs are indeed my main use case, they are quite generic and
> may not always have system memory backing them (device memory). Working
> at the CMA allocator alleviated these disparities.
> 
> > Explain what do you want to achieve and then we can think whether memcg
> > is the right model for that usecase
> 
> Hopefully I expressed this in a better way by now. In short, enforce
> usage limits for concurrent CMA users using shared CMA resources.

Thanks. Yes this is more clear now. And it resembles hugetlb situation
more than memcg. You simply need a memory pool specific access and usage
control. Dispersing that to a global memcg limit seems rather coarse and 
I would say impractical. So it really calls for a per pool control with
an understanding of how the specific pool really works.
-- 
Michal Hocko
SUSE Labs

On Wed, Aug 26, 2026 at 10:04:27AM +0200, Michal Hocko wrote:
> On Tue 25-08-26 16:58:51, Eric Chanudet wrote:
> > On Tue, Aug 25, 2026 at 09:19:21PM +0200, Michal Hocko wrote:
> > > On Tue 25-08-26 14:33:48, Eric Chanudet wrote:
> > > > On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> > > > [...]
> > > > The administrator opts in by mounting cgroupfs with
> > > > memory_cma_accounting. At which point the cma allocator will charge CMA
> > > > allocations against memcg and manages a per area counter depending on
> > > > what area the allocation was made into.
> > > 
> > > So each CMA area will have its own counter and limits?
> > 
> > Yes, in order to enforce a limit per CMA area this series add a page
> > counter for each area. Areas are fixed and discovered early so the
> > counters are added to struct mem_cgroup and initialized when the cgroup
> > is created.
> > 
> > An admin would then use the cgroupfs entries to assign an area limit to
> > a given cgroup, something like the following, using the reserved area
> > for example:
> >   mount -o remount,memory_cma_accounting /sys/fs/cgroup
> >   echo +memory > /sys/fs/cgroup/cgroup.subtree_control
> >   mkdir /sys/fs/cgroup/mycg
> >   echo 16M > /sys/fs/cgroup/mycg/memory.cma.reserved.max
> >   echo 64M > /sys/fs/cgroup/mycg/memory.max
> 
> OK, thanks for the clarification. This confirms my initial suspicion but
> it is better to have it clearly articulated. I can see several problems
> with this approach. First and formost I do not think dealing with all
> cmas this way is manageable. This can become a mess very quickly if we
> have one limit per cma and too coarse if there is a single one. I also
> have my doubts about space allocation control through a simple limit for
> something that is effectively a reserved physical space.
> 
> I might be proven wrong but unless cma serves objects of a uniform
> size then this will simply not work in practice. Hitting ENOSPC without
> hitting limits and thus impractical for shared space management.

Isn't that an inherent limit with CMA as it is? If the area gets
fragmented, some buffers may no longer be allocated since there is no
remaining hole big enough to accommodate them? I do hear that putting
arbitrary limits would make this worse, which might breach the threshold
at which it becomes a problem.

> 
> [...]
> 
> > > > It looked consistent to use memcg since movable pages from regular
> > > > allocations may end up in available CMA regions until a CMA allocation
> > > > needs the space and has them moved. So in an extreme case, hogging the
> > > > CMA space of a large enough area could trigger system memory pressure.
> > > 
> > > I really do not understand what you mean here. 
> > 
> > Non-CMA allocations can end up in CMA physical regions when necessary
> > (ALLOC_CMA flag).
> 
> Correct. But those are a subject of migration so any such placement
> should not be blocking real CMA allocations.
> 
> > Since both CMA allocations and other system
> > allocations are represented the same way, with differences only in
> > properties, and they can live in the same regions, it sounds reasonable
> > to account for both under the same counter.
> 
> From the memcg POV we do account physically consumed memory. So yes,
> it makes no difference where the memory comes from. We only care about
> the overall capacity you can constrain or protect. Generally speaking it
> makes sense to charge heavy memory consumers directly triggerable from
> the userspace.
> 
> That is all memcg can provide you with. Specific requirements for
> specific types of memory is a different story. We currently cannot
> control per-numa node for example. There is an ongoing work to make
> memcg memory tier aware. 
> 
> > > > > > memcg looked like a good fit to achieve this, albeit
> > > > > > handling the areas, so a cgroup has a quota in a given CMA
> > > > > > resource.
> > > > > 
> > > > > Please expand more on why do you think this fits into the memcg model.
> > > > > AFAIU we are talking about a unreclaimable memory and reservations of
> > > > > CMA areas.
> > > > 
> > > > Since memcg already accounts for some unreclaimable memory (kmem,
> > > > hugetlb),
> > > 
> > > hugetlb pages have their own controller
> > > 
> > > > or induces failure if no reclamation is possible, I did not
> > > > see CMA allocations being unreclaimable to be a blocker to track what is
> > > > otherwise system memory.
> > > 
> > > yes, we can have unreclaimable memory charged to memcg, that is not a
> > > real problem. We have all sorts of memory consumers that need to be
> > > capped charged to the memcg. If dmabufs are another ones then fine, just
> > > charge allocated pages from the cma area. It is the "make all cma users
> > > memcg aware and have per cma limits" that I am really struggling with.
> > 
> > CMA is system memory independently from its usage though, and in cases
> > with shared CMA areas multiple users can allocate from them. Yet the
> > kernel cannot enforce usage limits.
> 
> Correct. Those are effectively a shared memory pools without any
> control. I do not think memcg is a good method to enfore any usage
> limits for that though for reasons mentioned above. Memcg is effective
> at capping the overall memory consumption of a workload. Not really
> great when it comes to a specific memory pool control.

Understood, that makes sense, and with the reclaim scenario mentioned
earlier, it doesn't fit.

> > > You cannot really assume usecase, requirements, lifetime etc. for an
> > > arbitrary cma area. I do not think this is a viable way forward. Focus
> > > on your real usecase, which seems to be dmabufs.
> > 
> > While dmabufs are indeed my main use case, they are quite generic and
> > may not always have system memory backing them (device memory). Working
> > at the CMA allocator alleviated these disparities.
> > 
> > > Explain what do you want to achieve and then we can think whether memcg
> > > is the right model for that usecase
> > 
> > Hopefully I expressed this in a better way by now. In short, enforce
> > usage limits for concurrent CMA users using shared CMA resources.
> 
> Thanks. Yes this is more clear now. And it resembles hugetlb situation
> more than memcg. You simply need a memory pool specific access and usage
> control. Dispersing that to a global memcg limit seems rather coarse and 
> I would say impractical. So it really calls for a per pool control with
> an understanding of how the specific pool really works.

Thank you for the feedback. It looks like this won't work. It also
excludes the attempt through double charging dmem[1] as it would have
similar issues trying to use memcg.

From your last sentence, would this rather call for a different
controller entirely that would handle CMA semantics? Referencing the
other thread[2] it would also make the charging separate from the
allocator, but simplify making it opt-in at the user's implementation,
e.g, the dmabuf heap would call some cma_cgroup_try_charge() and
cma_cgroup_uncharge() around cma_alloc()/cma_release().

[1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/
[2] https://lore.kernel.org/all/7e4e9662-d876-4493-a0b3-e31640937dd1@kernel.org/

> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Eric Chanudet

On Wed 26-08-26 16:31:56, Eric Chanudet wrote:
> On Wed, Aug 26, 2026 at 10:04:27AM +0200, Michal Hocko wrote:
> > On Tue 25-08-26 16:58:51, Eric Chanudet wrote:
> > > On Tue, Aug 25, 2026 at 09:19:21PM +0200, Michal Hocko wrote:
> > > > On Tue 25-08-26 14:33:48, Eric Chanudet wrote:
> > > > > On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > The administrator opts in by mounting cgroupfs with
> > > > > memory_cma_accounting. At which point the cma allocator will charge CMA
> > > > > allocations against memcg and manages a per area counter depending on
> > > > > what area the allocation was made into.
> > > > 
> > > > So each CMA area will have its own counter and limits?
> > > 
> > > Yes, in order to enforce a limit per CMA area this series add a page
> > > counter for each area. Areas are fixed and discovered early so the
> > > counters are added to struct mem_cgroup and initialized when the cgroup
> > > is created.
> > > 
> > > An admin would then use the cgroupfs entries to assign an area limit to
> > > a given cgroup, something like the following, using the reserved area
> > > for example:
> > >   mount -o remount,memory_cma_accounting /sys/fs/cgroup
> > >   echo +memory > /sys/fs/cgroup/cgroup.subtree_control
> > >   mkdir /sys/fs/cgroup/mycg
> > >   echo 16M > /sys/fs/cgroup/mycg/memory.cma.reserved.max
> > >   echo 64M > /sys/fs/cgroup/mycg/memory.max
> > 
> > OK, thanks for the clarification. This confirms my initial suspicion but
> > it is better to have it clearly articulated. I can see several problems
> > with this approach. First and formost I do not think dealing with all
> > cmas this way is manageable. This can become a mess very quickly if we
> > have one limit per cma and too coarse if there is a single one. I also
> > have my doubts about space allocation control through a simple limit for
> > something that is effectively a reserved physical space.
> > 
> > I might be proven wrong but unless cma serves objects of a uniform
> > size then this will simply not work in practice. Hitting ENOSPC without
> > hitting limits and thus impractical for shared space management.
> 
> Isn't that an inherent limit with CMA as it is? If the area gets
> fragmented, some buffers may no longer be allocated since there is no
> remaining hole big enough to accommodate them? I do hear that putting
> arbitrary limits would make this worse, which might breach the threshold
> at which it becomes a problem.

I wanted to say that a limit for something that is basically a
reservation problem for shared pool is an ineffective solution.
Exactly for reasons you are mentioning. You might set limits for parties
sharing the same pool but that will not ensure they will be able to use
their promised portion - that makes low,min limits effectively
impossible. And hard/high limits are only to stop runaways.

[...]

> > Thanks. Yes this is more clear now. And it resembles hugetlb situation
> > more than memcg. You simply need a memory pool specific access and usage
> > control. Dispersing that to a global memcg limit seems rather coarse and 
> > I would say impractical. So it really calls for a per pool control with
> > an understanding of how the specific pool really works.
> 
> Thank you for the feedback. It looks like this won't work. It also
> excludes the attempt through double charging dmem[1] as it would have
> similar issues trying to use memcg.
> 
> >From your last sentence, would this rather call for a different
> controller entirely that would handle CMA semantics?

I would recommend focusing on specific CMA users rather than trying to
define a sane semantic for all potential CMA users because that might be
a lot of different things.
Then I would suggest focusing on the ultimate goal. Do you really want
to provide any sort of guarantees (a reservation system) for a shared
pool or merely cap maximum usage.
Last but not least think about whether the whole sharing of a
constrained memory area between uncooperative parties really makes sense
in the first place. Especially when the pool serves objects of different
sizes and fragmentation becomes a real problem.

> [1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/
> [2] https://lore.kernel.org/all/7e4e9662-d876-4493-a0b3-e31640937dd1@kernel.org/
> 
> > -- 
> > Michal Hocko
> > SUSE Labs
> > 
> 
> -- 
> Eric Chanudet

-- 
Michal Hocko
SUSE Labs

Hi Eric,

On Fri, Aug 21, 2026 at 02:56:52PM -0400, Eric Chanudet wrote:
> CMA allocations are currently unaccounted for by cgroup memory
> controllers. As system resources, they should fall under memcg, but CMA
> areas partition the available space for different purposes and memcg
> doesn't have a good representation for that.
> 
> Add a memory_cma_accounting cgroupfs option in preparation for the
> following new behavior. Make it disabled by default since it will
> account for CMA allocations in memcg which may affect existing systems.
> 
> Provide CMA charge/uncharge functions to memcg that introduce a CMA area
> specific counter per CMA area. Charges are issued to memcg and to a page
> counter for the CMA area used. The allocation's folios are marked with
> the cgroup via commit_charge() (once for large folios, per-page for
> 0-order ones) so they can be later uncharged correctly.
> 
> Add the new memcg calls into the cma allocator under __cma_alloc_frozen,
> for both cma and hugetlb_cma allocations accounting.
> 
> Finally register the per-area usage counters in the cgroupfs. Each CMA
> area creates a memory.cma.<area>.{current,max} pair for reporting and
> limitation for each area.
> 
> Selftests and a vmtest script are added to this series for convenience.
> The tests are simple accounting and limit enforcement verification using
> the default reserved CMA area (cma=) and hugetlb_cma.
> 
> Signed-off-by: Eric Chanudet <echanude@redhat.com>
> ---
> Eric Chanudet (11):
>       mm/cma: drop const for struct page on release API
>       mm/cma: include linux/cma.h in cma.h
>       cgroup: add memory_cma_accounting mount option
>       memcg: add cma charge/uncharge functions for area counters
>       mm/cma: charge cma allocation to memcg per area counters
>       memcg: register per-area usage counters in cgroupfs
>       selftests: cgroup: add cma configs for cgroup selftest suite
>       selftests: cgroup: add memcg cma tests
>       selftests: cgroup: add a vmtest script for memcg
>       selftests: cgroup: add memcg hugetlb_cma tests
>       selftests: cgroup: amend vmtest-memcg to run the hugetlb cma tests

CI found issues:
 
https://github.com/linux-mm/linux-mm/actions/runs/32519133924

>  Documentation/admin-guide/cgroup-v2.rst         |  35 +++
>  include/linux/cgroup-defs.h                     |   5 +
>  include/linux/cma.h                             |   4 +-
>  include/linux/memcontrol.h                      |  19 ++
>  kernel/cgroup/cgroup.c                          |  15 +-
>  mm/cma.c                                        |  14 +-
>  mm/cma.h                                        |   6 +
>  mm/cma_debug.c                                  |   1 -
>  mm/cma_sysfs.c                                  |   1 -
>  mm/memcontrol.c                                 | 205 ++++++++++++
>  tools/testing/selftests/cgroup/.gitignore       |   1 +
>  tools/testing/selftests/cgroup/Makefile         |   2 +
>  tools/testing/selftests/cgroup/config           |   5 +
>  tools/testing/selftests/cgroup/test_cma_memcg.c | 402 ++++++++++++++++++++++++
>  tools/testing/selftests/cgroup/vmtest-memcg.sh  | 197 ++++++++++++
>  15 files changed, 903 insertions(+), 9 deletions(-)
> ---
> base-commit: 98f21c54f99519329c18e2625b0ea6db14524d09
> change-id: 20260706-cma-memcg-regions-696cb5ef7998
> 
> Best regards,
> -- 
> Eric Chanudet <echanude@redhat.com>
> 

-- 
Sincerely yours,
Mike.

On Sun, Aug 23, 2026 at 10:02:35AM +0300, Mike Rapoport wrote:
> Hi Eric,
> 
> On Fri, Aug 21, 2026 at 02:56:52PM -0400, Eric Chanudet wrote:
> > CMA allocations are currently unaccounted for by cgroup memory
> > controllers. As system resources, they should fall under memcg, but CMA
> > areas partition the available space for different purposes and memcg
> > doesn't have a good representation for that.
> > 
> > Add a memory_cma_accounting cgroupfs option in preparation for the
> > following new behavior. Make it disabled by default since it will
> > account for CMA allocations in memcg which may affect existing systems.
> > 
> > Provide CMA charge/uncharge functions to memcg that introduce a CMA area
> > specific counter per CMA area. Charges are issued to memcg and to a page
> > counter for the CMA area used. The allocation's folios are marked with
> > the cgroup via commit_charge() (once for large folios, per-page for
> > 0-order ones) so they can be later uncharged correctly.
> > 
> > Add the new memcg calls into the cma allocator under __cma_alloc_frozen,
> > for both cma and hugetlb_cma allocations accounting.
> > 
> > Finally register the per-area usage counters in the cgroupfs. Each CMA
> > area creates a memory.cma.<area>.{current,max} pair for reporting and
> > limitation for each area.
> > 
> > Selftests and a vmtest script are added to this series for convenience.
> > The tests are simple accounting and limit enforcement verification using
> > the default reserved CMA area (cma=) and hugetlb_cma.
> > 
> > Signed-off-by: Eric Chanudet <echanude@redhat.com>
> > ---
> > Eric Chanudet (11):
> >       mm/cma: drop const for struct page on release API
> >       mm/cma: include linux/cma.h in cma.h
> >       cgroup: add memory_cma_accounting mount option
> >       memcg: add cma charge/uncharge functions for area counters
> >       mm/cma: charge cma allocation to memcg per area counters
> >       memcg: register per-area usage counters in cgroupfs
> >       selftests: cgroup: add cma configs for cgroup selftest suite
> >       selftests: cgroup: add memcg cma tests
> >       selftests: cgroup: add a vmtest script for memcg
> >       selftests: cgroup: add memcg hugetlb_cma tests
> >       selftests: cgroup: amend vmtest-memcg to run the hugetlb cma tests
> 
> CI found issues:
>  
> https://github.com/linux-mm/linux-mm/actions/runs/32519133924

Indeed my apologies, I messed up CMA=n it needed a forward declaration
and gating for mm/cma.h content included in mm/memcontrol.c.

I queued this up for a v2, with the other issues reported by Sashiko.

> 
> >  Documentation/admin-guide/cgroup-v2.rst         |  35 +++
> >  include/linux/cgroup-defs.h                     |   5 +
> >  include/linux/cma.h                             |   4 +-
> >  include/linux/memcontrol.h                      |  19 ++
> >  kernel/cgroup/cgroup.c                          |  15 +-
> >  mm/cma.c                                        |  14 +-
> >  mm/cma.h                                        |   6 +
> >  mm/cma_debug.c                                  |   1 -
> >  mm/cma_sysfs.c                                  |   1 -
> >  mm/memcontrol.c                                 | 205 ++++++++++++
> >  tools/testing/selftests/cgroup/.gitignore       |   1 +
> >  tools/testing/selftests/cgroup/Makefile         |   2 +
> >  tools/testing/selftests/cgroup/config           |   5 +
> >  tools/testing/selftests/cgroup/test_cma_memcg.c | 402 ++++++++++++++++++++++++
> >  tools/testing/selftests/cgroup/vmtest-memcg.sh  | 197 ++++++++++++
> >  15 files changed, 903 insertions(+), 9 deletions(-)
> > ---
> > base-commit: 98f21c54f99519329c18e2625b0ea6db14524d09
> > change-id: 20260706-cma-memcg-regions-696cb5ef7998
> > 
> > Best regards,
> > -- 
> > Eric Chanudet <echanude@redhat.com>
> > 
> 
> -- 
> Sincerely yours,
> Mike.
> 

-- 
Eric Chanudet

On Mon 24-08-26 17:58:49, Eric Chanudet wrote:
> On Sun, Aug 23, 2026 at 10:02:35AM +0300, Mike Rapoport wrote:
[...]
> > CI found issues:
> >  
> > https://github.com/linux-mm/linux-mm/actions/runs/32519133924
> 
> Indeed my apologies, I messed up CMA=n it needed a forward declaration
> and gating for mm/cma.h content included in mm/memcontrol.c.
> 
> I queued this up for a v2, with the other issues reported by Sashiko.

Let's focus on the highlevel design and usecase disussion first before
you start chasing specific implementation details.

-- 
Michal Hocko
SUSE Labs

Hi Eric.

On Fri, Aug 21, 2026 at 02:56:52PM -0400, Eric Chanudet <echanude@redhat.com> wrote:
> Finally register the per-area usage counters in the cgroupfs. Each CMA
> area creates a memory.cma.<area>.{current,max} pair for reporting and
> limitation for each area.

These areas quite resemble dmem regions.
What is the relation to the previous dmem double-charging [1]?
(Successor, alternative,...)

Thanks,
Michal

On Mon, Aug 24, 2026 at 03:18:54PM +0200, Michal Koutný wrote:
> Hi Eric.
> 
> On Fri, Aug 21, 2026 at 02:56:52PM -0400, Eric Chanudet <echanude@redhat.com> wrote:
> > Finally register the per-area usage counters in the cgroupfs. Each CMA
> > area creates a memory.cma.<area>.{current,max} pair for reporting and
> > limitation for each area.
> 
> These areas quite resemble dmem regions.
> What is the relation to the previous dmem double-charging [1]?
> (Successor, alternative,...)

They are, although I did not make it clear in the cover letter, my bad.

This is a CMA centric alternative to the other series that tried to
issue the memcg charge through dmem[1]. CMA seemed to better fit under
memcg directly as I couldn't find a solution on how to correctly charge
memcg once in dmem where it was determined to double-charge or not.

[1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/

> 
> Thanks,
> Michal



-- 
Eric Chanudet