Re: [PATCH 00/11] mm/cma: charge cma allocation to memcg using per area counters

["David Hildenbrand (Arm)" <david@kernel.org>]

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