From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CEDA37AA7C for ; Mon, 2 Feb 2026 15:18:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770045541; cv=none; b=KFVwzPvZFzN+Hgp6PbEzOphvUiaZ35fL4sv0YsV44tESKWHb2619NrQMXBEjcekRN3xjKE6hodLxNsuHtopEw+1x1PynR1d5NykLbP9mjrCUJ3fmjGbfXHmdGMh5wVWXAKgxDTegVcLC/zVasdexpstF9BUeRNrX0Q8jxNnj48k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770045541; c=relaxed/simple; bh=D0/NVhS//i0LKf6hyciVN+qtrVAfDmdrxWdqjeDWXdA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kFbaSAgaVIVdh6C13HSVe0eEIbmzBjxEIGFewkGRg8Ci5SlzPOEQJeM4u6EUR6OpDBtatYSl7gTSrcrIe7UzTvSd/wOCHGITw3Na9Bmz0YK0RN6pQf66VISO92tWc+Pp9iu0FRy9+4OAqh0w/tbuUKe21IhkIAoeJ4w9XQ8e4ys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QiQE2wdS; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=HD/e4OCu; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QiQE2wdS"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="HD/e4OCu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770045538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IAa9rUiFokLsL02HcrzVefKkv/ss8oRA4iFHEcIfETc=; b=QiQE2wdStdckCYxDzoOBEUVG38+pAdcXRqWagMpauswXJFGGO5DmPLyPAxsIuHq5Es7ZyS x4XUNC5ZpZ1Dz87TN+Mr4zgj4ziYSMD/B7fDVTPKodxlncuUto5xm6j2HY1OMPr8rwTAzz O0XPjbOTmPZ5jhoNsYonQQo1w9C4O4g= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-407-eh01MmIBP6mpDGlR1aJlmw-1; Mon, 02 Feb 2026 10:18:57 -0500 X-MC-Unique: eh01MmIBP6mpDGlR1aJlmw-1 X-Mimecast-MFC-AGG-ID: eh01MmIBP6mpDGlR1aJlmw_1770045537 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-89470bda22aso145024696d6.1 for ; Mon, 02 Feb 2026 07:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770045537; x=1770650337; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IAa9rUiFokLsL02HcrzVefKkv/ss8oRA4iFHEcIfETc=; b=HD/e4OCume1oKlMZW+/kS5Xl2rtD9lzk1cYZgUESPksZoQ7Dksm2wMbNZtbteB2D2e u9C2Y/kbGXHdw+zlQHdadoQkbroSpMGLuAbh57sil+Z32cqPMjQ9sE4MTb4C8yshvOY1 0OBYNn5KEZVbTmVn2LrqvYQZpolNEVUXr4ll9vYKsoYJUTn8QVXfNsYBsZEC8kXmU3ko diaTac8Qse2kPNTBP3ulao7OXGs1Vi5uBvqXlRVRwxPpy9AsO1PdxlJS7FDznY92R4Pb Mkm+r+aTJj4+sBLpy4KLI+zenkl9Vu0yY8ORTDHVtq8YMVtmCQ+Ac+vxqWCsjbnw1ag0 C5Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770045537; x=1770650337; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IAa9rUiFokLsL02HcrzVefKkv/ss8oRA4iFHEcIfETc=; b=Le7nRY8lWK16VPNQARrAJRkPC+xkQ6xNloo9SLR4/ncl+U4UD6RafUojy8ugk0Ae6C goyqtiaAm8xibVYFDMba+ha6WxEWl+r8pyR4ajBY70Rm98554k5m6B2qpzCmnv9ptB/8 F0t9/RwC70EIENS9iWFMuHGYxjdymW6B5sBgwQI1nON/VXCsyg1ZA/qkJVK3dIpN5t1i TI1PYQv+/tdJnhE3kYm+BcVOlPmNEJOOOCxoXu3VwYVT42GbnasK6aR0siG08SMFh6G+ ljmhCapscCop8ftEk/L1FjRQkFM7x2m2DjJc5sjTZmHbYNJrsDZQNjR2VsGynPcYn/RD 8XwA== X-Forwarded-Encrypted: i=1; AJvYcCXfJczkIsMmFdRI72n9BdDXP9kfek+ILFWe+Mo/ffTuw1jY1TjEPqq6R5HnH9em7R8GMc4yKSf1F2LKlu4=@vger.kernel.org X-Gm-Message-State: AOJu0YzCGdAmkXKo7/97IeUWQbL4Q/8lb71u16rvokd94wDVfNr63aPJ jdq+3TafqQDFT59y191MMRrgjWVnHYkeQRteGL0ZxnpEe2EedZNNbpLv/7yUOAI35GLkTuTZTBy KVmFxkmKK5lBszsTPAe6XPK7gW7LYgB6pI6zl21KSufHmkUublMXTwFbjl5kl5KUwow== X-Gm-Gg: AZuq6aJwNob3LCJ05eNpKOtCjJEbAlqhMg65FQ4mmPWYgQgPa6oeRh39OlrcVrUYYyH vJGIMFvSEg/2mUKaAiFaZpUUauh9rMMjnSTOARdOXDOrq6ZL4mXyoMrfDst/Q4rGVlY7iDxpu7u AWIHHSvFZE7sgpmezejFHOcaGZr3lBs1icuMZs2/bEWf+MftUEbgCAzdece50aGfp3Wvh9yMKE+ Z6K9tZ/C/js2MYEniuLDvwIBLD2j4Z8/Nl99Xo3exZWMAkDkbYmop3mYsAhICiEWU0fB/KMNTn+ ZJilC4TXaaBw8qWwwjfWjK6Fjw9fJFm4gcnpVfr7QqC+R659Cj/Dy4YqMow8BVY6XOtWsG3GIhV mHXdFR5McmkvkamlDyvMkXEqEx2YdU8qgJNM8qYoR9oS4Etw5GoM= X-Received: by 2002:a05:6214:764:b0:894:2cf7:7171 with SMTP id 6a1803df08f44-894e9f79920mr169707866d6.28.1770045536545; Mon, 02 Feb 2026 07:18:56 -0800 (PST) X-Received: by 2002:a05:6214:764:b0:894:2cf7:7171 with SMTP id 6a1803df08f44-894e9f79920mr169706896d6.28.1770045535786; Mon, 02 Feb 2026 07:18:55 -0800 (PST) Received: from localhost (pool-100-17-19-56.bstnma.fios.verizon.net. [100.17.19.56]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c711b7c7besm1249530285a.2.2026.02.02.07.18.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 07:18:55 -0800 (PST) Date: Mon, 2 Feb 2026 10:18:54 -0500 From: Eric Chanudet To: Maxime Ripard Cc: Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Christian =?utf-8?B?S8O2bmln?= , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, Albert Esteve Subject: Re: [PATCH] dma-buf: heaps: cma: register a dmem region for each cma heap Message-ID: References: <20260130-dmabuf-heap-cma-dmem-v1-1-3647ea993e99@redhat.com> <20260202-wealthy-quick-cow-8c5421@houat> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260202-wealthy-quick-cow-8c5421@houat> On Mon, Feb 02, 2026 at 11:12:37AM +0100, Maxime Ripard wrote: > Hi, > > On Fri, Jan 30, 2026 at 05:55:30PM -0500, Eric Chanudet wrote: > > The cma dma-buf heaps let userspace allocate buffers in CMA regions > > without enforcing limits. Register a dmem region per cma heap and charge > > against it when allocating a buffer in a cma heap. > > > > For the default cma region, two heaps may be created for the same cma > > range: > > commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name") > > Introduced /dev/dma_heap/default_cma_region > > commit 4f5f8baf7341 ("dma-buf: heaps: cma: Create CMA heap for each CMA > > reserved region") > > Created a CMA heap for each CMA region, which might create a duplicate > > heap to the default one, e.g: > > /dev/dma_heap/default_cma_region > > /dev/dma_heap/reserved > > > > Removing the legacy heap would break user API. So handle the special > > case by using one dmem between the two heaps to account charges > > correctly. > > > > Signed-off-by: Eric Chanudet > > --- > > In continuation with introducing cgroup for the system heap[1], this > > behavior is enabled based on dma_heap.mem_accounting, disabled by > > default. > > > > dmem is chosen for CMA heaps as it allows limits to be set for each > > region backing each heap. There is one caveat for the default cma range > > that may accessible through two different cma heaps, which is treated as > > a special case. > > > > [1] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ecc6b62cc446@redhat.com/ > > --- > > drivers/dma-buf/heaps/cma_heap.c | 51 ++++++++++++++++++++++++++++++++++++---- > > 1 file changed, 46 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > > index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..608af8ad6bce7fe0321da6d8f1b65a69f5d8d950 100644 > > --- a/drivers/dma-buf/heaps/cma_heap.c > > +++ b/drivers/dma-buf/heaps/cma_heap.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > > > #define DEFAULT_CMA_NAME "default_cma_region" > > > > @@ -46,7 +47,9 @@ int __init dma_heap_cma_register_heap(struct cma *cma) > > struct cma_heap { > > struct dma_heap *heap; > > struct cma *cma; > > + struct dmem_cgroup_region *cg; > > }; > > +static struct dmem_cgroup_region *default_cma_cg; > > > > struct cma_heap_buffer { > > struct cma_heap *heap; > > @@ -58,6 +61,7 @@ struct cma_heap_buffer { > > pgoff_t pagecount; > > int vmap_cnt; > > void *vaddr; > > + struct dmem_cgroup_pool_state *pool; > > }; > > > > struct dma_heap_attachment { > > @@ -276,6 +280,7 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) > > kfree(buffer->pages); > > /* release memory */ > > cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); > > + dmem_cgroup_uncharge(buffer->pool, buffer->len); > > kfree(buffer); > > } > > > > @@ -319,9 +324,16 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, > > if (align > CONFIG_CMA_ALIGNMENT) > > align = CONFIG_CMA_ALIGNMENT; > > > > + if (mem_accounting) { > > + ret = dmem_cgroup_try_charge(cma_heap->cg, size, > > + &buffer->pool, NULL); > > + if (ret) > > + goto free_buffer; > > + } > > > > cma_pages = cma_alloc(cma_heap->cma, pagecount, align, false); > > if (!cma_pages) > > - goto free_buffer; > > + goto uncharge_cgroup; > > > > /* Clear the cma pages */ > > if (PageHighMem(cma_pages)) { > > @@ -376,6 +388,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, > > kfree(buffer->pages); > > free_cma: > > cma_release(cma_heap->cma, cma_pages, pagecount); > > +uncharge_cgroup: > > + dmem_cgroup_uncharge(buffer->pool, size); > > Should we make that conditional on mem_accounting == true ? > > > free_buffer: > > kfree(buffer); > > > > @@ -390,25 +404,52 @@ static int __init __add_cma_heap(struct cma *cma, const char *name) > > { > > struct dma_heap_export_info exp_info; > > struct cma_heap *cma_heap; > > + struct dmem_cgroup_region *region; > > + int ret; > > > > cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL); > > if (!cma_heap) > > return -ENOMEM; > > cma_heap->cma = cma; > > > > + /* > > + * If two heaps are created for the default cma region, use the same > > + * dmem for them. They both use the same memory pool. > > + */ > > + if (dev_get_cma_area(NULL) == cma && default_cma_cg) > > + region = default_cma_cg; > > + else { > > + region = dmem_cgroup_register_region(cma_get_size(cma), "cma/%s", name); > > + if (IS_ERR(region)) { > > + ret = PTR_ERR(region); > > + goto free_cma_heap; > > + } > > + } > > + cma_heap->cg = region; > > + > > I'm not sure it's the best way to go with this. We want to track all > relevant CMA allocations going forward, in the heaps and elsewhere. > > If we were to do what you suggest, an allocation in, say, DRM or v4l2 > wouldn't be tracked in the same region than one in the heaps, while we > want to have it cumulated. > > I think we'd be better off if we created a dmem region for each CMA > region in the system, but we would charge from the heap so we don't > account for every allocation. That makes more sense. I will do that in a v2. > I don't think we can register the dmem region when the CMA area is > initialized though, since it will probably be too early in the kernel > boot and SLAB isn't around yet. > > But since we would need an accessor to get a dmem region from a cma > region, we could do something like check if a dmem eregion already > exists for that cma region, and allocate one otherwise. Or have a > secondary initcall to allocate all dmem regions. In an earlier series[1], you did this during cma_activate_area(), core_initcall is late enough, so I can start from this in your series. [1] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-1-2984c1bc9312@kernel.org/ > > Maxime -- Eric Chanudet