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 07C1C3563F0 for ; Mon, 2 Feb 2026 10:12:42 +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=1770027164; cv=none; b=CCOWoAuNCKddTl5xMqJcKFpjOo7ISTo9YB36zdM4E4O6v+2mowNi1tYtUQWaHAHARl89/H2Roish+Pgzb0rt+QjY868h1Bp2xRuv4eyBPKBzSzLkyQCFijuyn3fG2cFtodWD9Rb+cJ40NUH7gBdv504UT5cxu/hK0sZCj3CIVUk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770027164; c=relaxed/simple; bh=+54t9JXO7n+eXPdANWOp0RpcdZIaJgMYBRBapxAnQOI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PO+T5yylllJHuFUY0BTjyKUR9cKeFlTccRl7ffBaOztIREGd9HU0Pgq6CyzHkd6XOlzG9BwMywn04/lZ8wEhaEt/nbpxJOIfc8013zjZ9FxbM/aYfepASQmapHomWH7yhxsF8kgd96crahyxGvgsATXyIxmE24gv9vj/MX1bsR0= 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=c1J3hUex; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=oqH09scm; 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="c1J3hUex"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="oqH09scm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770027162; 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=T8trzVS4ZUCHrBPpOVXGPFbB+m6G0A2WMMBaMJLn58s=; b=c1J3hUexP3c8TKmy7G1BL+02diZtlGzmE4nUvaczA9Uo2rvOTNWaWECRY4xk+7SbPxTQ7p /RiTOWgnMZIjG4P7pU1kvswtSgIifb8Zr6yKSr9qtW2FTgeJBiOQBXG1vdUNwyNT2+nr4f Roo0rG0Sovp6RvhTubx5UCnXTl3dQO0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-467-es_dg3ZMMZWvkd6Ocb3_FA-1; Mon, 02 Feb 2026 05:12:40 -0500 X-MC-Unique: es_dg3ZMMZWvkd6Ocb3_FA-1 X-Mimecast-MFC-AGG-ID: es_dg3ZMMZWvkd6Ocb3_FA_1770027159 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-482eec44485so13675885e9.3 for ; Mon, 02 Feb 2026 02:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770027159; x=1770631959; 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=T8trzVS4ZUCHrBPpOVXGPFbB+m6G0A2WMMBaMJLn58s=; b=oqH09scm8tZr9T2nN1Cfq7lQQOa+2HDrxsRmxmOcosPLG7fxwLO+4Y26QJU3o50nG9 auJ5MZwIQEZWU+oD/Jc468TGwa9IqZPpahX4JPsIL6oXLv+M900QbTngNePhRWWWu1Cx F3i5up0c1iIN0iI0NuyuP2W4HZ+0v0Y/f/NWaUtTCgTkvYC6gUcnonwqUCdOWoOxTtLX sGUIW/lHrkbjRvn8tgz7GIf3PLDJkb5FWPALj5D7S1QCZyyPzzeGKuz+htxPoYl27pNs Ng3bF+wMPdEp/wc/pGAiJEcJ9ZlbHLcTHDwNrNo6B5yD8oJhSFPZFQQvVaHwW+dvtopf xKgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770027159; x=1770631959; 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=T8trzVS4ZUCHrBPpOVXGPFbB+m6G0A2WMMBaMJLn58s=; b=XdNWIF5Onu/0aqA1uiJk6fBhj5Ny1yoOr8HcvIXKpm0Y3UG7GtKLAOGWO+YKCJvGSO P1SDOKlaGARjAg12S2sMgN51qxg6VPa4px+i0H+o+jb5wvYlK7PXaFUCavzAAHorSa9n 3MMO/BOD+QCSmHWNkLKGr6+YHBsxLcKsubrEXZOdCztxn3UMUdK24d7sor2P0FM9H9hL 9TPeP+w/wCs4G6yc1f66NCGuOj6RtS/SFQ3imyS7fezQ2a3XrdsS9UaLGuYm149YQ61w AX402wEWCZcmOHPDNQ7V9gLVlIzKOvenMhU2K/F5r60xrBnRbk48ijt6/IrXTuc7Wvok jI0g== X-Forwarded-Encrypted: i=1; AJvYcCX5FmVigXNns3YS1z6feE/5R+2g+hl9Hrph+9uAam/1KJk+0GFkB9YP1aZUcs2N1FHqAD64fgMdbbQPJ74=@vger.kernel.org X-Gm-Message-State: AOJu0Yxrsq1d+kxUJeB9rJRtD/tMAXJbgP+GU6Ac/bgT+i+Y4rnq4ueW NyA/jJaccg0xDW1ZwydmYNdO4YDZaC+ufe44dtW98tHwiWzeAlzJ+kg48pCM+IhMyKMY8Fw/W+Z AF2gOev8oevUv4Qq3unDwigawX9/203/81Zb7Ty8OvYntXMw1I4lhyW0i80RBgTSQDw== X-Gm-Gg: AZuq6aKTsmymSQUInMj95rCZH/JTOZTjVmkv+PGmxbhRJWtDvXvtH/pxxdJ50Hlqd7z 8/QqCSoOwmxfluuR84Vx6hIbIw3BNdZykQu3+zaVpPfuP2kCfMLhw6Fx2ijvz3RfhECrRPs1+3s h6gtzM0YSq851V03NCAwfqKQc7XHN/IsA0jgIoRYS2NywjmHfsGBkASBYVQFIOk7MpViIaFe6Kj 3PPgmyKLK90+F6voc3RhAshibrhoUFnAYNrn1AGcF1vR81583YqIoEG80YjGYUDoad5E0HGgJFy 2ZcSGHGDN1o5CJt0+R2CXtsUElOLSDa75JHWIecef2+87YAXYeoaowKFRpFv7A== X-Received: by 2002:a05:600c:6092:b0:47a:7fdd:2906 with SMTP id 5b1f17b1804b1-482db45441fmr144478725e9.12.1770027158995; Mon, 02 Feb 2026 02:12:38 -0800 (PST) X-Received: by 2002:a05:600c:6092:b0:47a:7fdd:2906 with SMTP id 5b1f17b1804b1-482db45441fmr144478255e9.12.1770027158488; Mon, 02 Feb 2026 02:12:38 -0800 (PST) Received: from localhost ([2a01:e0a:b25:f902::ff]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cddffe9sm555222985e9.4.2026.02.02.02.12.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 02:12:37 -0800 (PST) Date: Mon, 2 Feb 2026 11:12:37 +0100 From: Maxime Ripard To: Eric Chanudet 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: <20260202-wealthy-quick-cow-8c5421@houat> References: <20260130-dmabuf-heap-cma-dmem-v1-1-3647ea993e99@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="ourfsz72devil6zd" Content-Disposition: inline In-Reply-To: <20260130-dmabuf-heap-cma-dmem-v1-1-3647ea993e99@redhat.com> --ourfsz72devil6zd Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] dma-buf: heaps: cma: register a dmem region for each cma heap MIME-Version: 1.0 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. >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > [1] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ec= c6b62cc446@redhat.com/ > --- > drivers/dma-buf/heaps/cma_heap.c | 51 ++++++++++++++++++++++++++++++++++= ++---- > 1 file changed, 46 insertions(+), 5 deletions(-) >=20 > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma= _heap.c > index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..608af8ad6bce7fe0321da6d8f= 1b65a69f5d8d950 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 > =20 > #define DEFAULT_CMA_NAME "default_cma_region" > =20 > @@ -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; > =20 > 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; > }; > =20 > 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); > } > =20 > @@ -319,9 +324,16 @@ static struct dma_buf *cma_heap_allocate(struct dma_= heap *heap, > if (align > CONFIG_CMA_ALIGNMENT) > align =3D CONFIG_CMA_ALIGNMENT; > =20 > + if (mem_accounting) { > + ret =3D dmem_cgroup_try_charge(cma_heap->cg, size, > + &buffer->pool, NULL); > + if (ret) > + goto free_buffer; > + } > > cma_pages =3D cma_alloc(cma_heap->cma, pagecount, align, false); > if (!cma_pages) > - goto free_buffer; > + goto uncharge_cgroup; > =20 > /* Clear the cma pages */ > if (PageHighMem(cma_pages)) { > @@ -376,6 +388,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_h= eap *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 =3D=3D true ? > free_buffer: > kfree(buffer); > =20 > @@ -390,25 +404,52 @@ static int __init __add_cma_heap(struct cma *cma, c= onst char *name) > { > struct dma_heap_export_info exp_info; > struct cma_heap *cma_heap; > + struct dmem_cgroup_region *region; > + int ret; > =20 > cma_heap =3D kzalloc(sizeof(*cma_heap), GFP_KERNEL); > if (!cma_heap) > return -ENOMEM; > cma_heap->cma =3D cma; > =20 > + /* > + * 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) =3D=3D cma && default_cma_cg) > + region =3D default_cma_cg; > + else { > + region =3D dmem_cgroup_register_region(cma_get_size(cma), "cma/%s", na= me); > + if (IS_ERR(region)) { > + ret =3D PTR_ERR(region); > + goto free_cma_heap; > + } > + } > + cma_heap->cg =3D 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. 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. Maxime --ourfsz72devil6zd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaYB4kAAKCRAnX84Zoj2+ dqPBAX9oydlm9YZRNx1uUYcnGj8czxCI9/nwwv3lTG3vB/96CaCaciG72JRvyD2+ YtcMBPEBf2UZP8KVV1tDJ+oujyCdJZXIsjWxMc55iL7AcfydJqlROACsQSaGrLgZ L+gEjF3czQ== =dD0c -----END PGP SIGNATURE----- --ourfsz72devil6zd--