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.133.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 C9B6D1A9FA8 for ; Mon, 23 Feb 2026 16:14:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771863275; cv=none; b=PSHwpsJCB/clrYD4wnVVdkA231ppnUj3lUdYeyPs2dSGsVkvbI29p55gCHSGSDvcxDSGGSSVqkMjqnLM7HXyU9vPEJAwgcbvffzmZEbP56iPgK8QxSpYLJYnWqkj9th//C2YI3U9FrK6reZoC/N92mQ8T85WXAhHzktx0TKXnrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771863275; c=relaxed/simple; bh=4ZZB0H+PZ1LR+m9pOc6Gi7z51bep34GW+4L4SAtIGSY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gLH7UnCZvb5ixBxPFr85GD3eeswd55Xa+MazJTQ2gXxpZJSOm6VoFEqUWg70dabnq4j4H/ZA01MeZ4RTUPDaxDMqNkWFeycDnvEb98pWnqOmUJCtyCSGUYuzmKgQlv87d1L8v+KWaj8y9MoljAdHqbufHLwNHqa14epwtsm8CmI= 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=Rz8ATTJ4; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Yxppz+UJ; arc=none smtp.client-ip=170.10.133.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="Rz8ATTJ4"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Yxppz+UJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771863272; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sRIkg/BYhLPQ8g8f8DScTuB2QESp5uVFZC6HG+ckSTg=; b=Rz8ATTJ4MoDaXNRzJNQzgbk8gkh2RqUKFcEHiabvWUwPjqD2BXEiTjYcZBF59GOHi9xYyo qtulacNANx8VIeSYxGa9DHSh8BvUgibMnO1mrdARgpKjg2j/jzywAbKRME0atC2NpnG14N 9+VbekVxK4p/v+IoECwFIREdjQ4K/j0= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-88-xVF4U9IwMk2Au_Q_uW2aIw-1; Mon, 23 Feb 2026 11:14:31 -0500 X-MC-Unique: xVF4U9IwMk2Au_Q_uW2aIw-1 X-Mimecast-MFC-AGG-ID: xVF4U9IwMk2Au_Q_uW2aIw_1771863271 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-506bac14430so200802971cf.2 for ; Mon, 23 Feb 2026 08:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1771863271; x=1772468071; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sRIkg/BYhLPQ8g8f8DScTuB2QESp5uVFZC6HG+ckSTg=; b=Yxppz+UJY1oVKOWtlzyTZd+oF2+YsNPxIZSmRDCiG2lx/F3RfW8bXPiFmh4QiBTKXQ S/wnXyWjje6D6OR/iPHgNEw+Koqr5BGCATDaefS1OZHqyCnoHksaLpEmhme/zK9jFq2F fuZRI2mi4oyRdwM5wy6x96dc/LqS737AlboFkHIsZMQrx2PGQeYtE32ITqWiKgOLYsPz WasMrnYGPklUdDPVIQPsQlfdTPnniY2vgvuttvndyEXkPxKWOYbDnci35xUqhCQUGawE XYsi9QoD+XS2PJ7HpUzC30VO204ArCf+JXgUD1gn+hzpSUrkfWI6jXR8ME0F1IMQvQ6H jCZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771863271; x=1772468071; h=in-reply-to:content-transfer-encoding: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=sRIkg/BYhLPQ8g8f8DScTuB2QESp5uVFZC6HG+ckSTg=; b=s0mJvD1b1YBQWNlBlebFVomorn/ibuKukhe2zK4RexDWlPfaLm7Yd+MNPhJiS71RLA omOyO34iAsiMkQ2jy8mLPlTh2h7drRdazgWmcQqCkXGLIpVWcYlvq+c9fyl9M1DTUe2E GDUmg+ZhZiqNMo6nmNvVpOAhyBMrovzshTVojTVphBn5AU0nrHnhlb/Ql4q1peTaaHot aXuBRpLmtM4FswX298sAEtfxKBX/MagHamXIvKFNAbvUhJ24GRbtb5oIiWVO7ELzX0kv eHvYskvEAAqG+ZdL/dGsUSKqHT4iXB4Vjh1uRwf0wNKmtaKstMLG0SMTQBsefSKAeuBF 2Ylw== X-Forwarded-Encrypted: i=1; AJvYcCXWfle0VRUy9Nqf3QjU0VaINrhR0wZ+X1VIxRNn9AwhZ6DPo8FIvCzIy3sR23TCXYEHCPeOJS2DZasnzZg=@vger.kernel.org X-Gm-Message-State: AOJu0YzZ/qQ+DB3gwRKf8WU1XBlmsmh0ta/J4nKmT6sZ4qHYDBGgbr/o X6H6nSGnjzH+UetRuMwlRtqGXebzECTXiykzE2NOi9bexV/pxRpOTnOhm/1uaPNz8OtlkSD7xwU mhAtMt7d1yLs7J+pI3BMK/oeBisd/3KvVF+JVhUaKL54BRZKSs92WDyZsbkrFIFaz8Q== X-Gm-Gg: AZuq6aJeh2AbaCrB2Gr6L1UiSXkILamD3SkGVjd4xtKLm3Agq3z6eIneEOC9cxsdJmy NfwbZ5tIqMsuezrBxp6fLMuxZxH/QrAmVZLrN28ZJnADPMrB/jmTAbb1sZWyXCarRlpKGI3gayj kL0/aI5tkuKDjgZpRBi1XtHYUpPQ+9GWVU23WolcfSQgrhmKPg7vHCUSa9x99pfG/5xO3AWloWr i6x/xbPpCR8PMT6jwW9IqhNIAr1EkOi3P80ghRr/8PBIx2M7kSSpFM+/jaL5M3eiZ3rJjMW3Ag6 zVwULK26OTXF1Qb2aZk3pyAZUeji5q5XS74UKceX4z9w6xfh2gXeBkTwfe6KxpnrNprrUrvIcpZ QTLlP+0ed4efhlkUIDtIGGzH8gshx4wSeWAl0H/4u8YpmVas1vVgkjFXkV/qsze0= X-Received: by 2002:a05:622a:1b9e:b0:501:17a9:5ff5 with SMTP id d75a77b69052e-5070bbd86aemr127614981cf.21.1771863270850; Mon, 23 Feb 2026 08:14:30 -0800 (PST) X-Received: by 2002:a05:622a:1b9e:b0:501:17a9:5ff5 with SMTP id d75a77b69052e-5070bbd86aemr127614251cf.21.1771863270296; Mon, 23 Feb 2026 08:14:30 -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 d75a77b69052e-5070d6a1ddasm71793581cf.21.2026.02.23.08.14.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 08:14:29 -0800 (PST) Date: Mon, 23 Feb 2026 11:14:29 -0500 From: Eric Chanudet To: Christian =?utf-8?B?S8O2bmln?= Cc: Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, Maxime Ripard , Albert Esteve , linux-mm@kvack.org Subject: Re: [PATCH v2 3/3] dma-buf: heaps: cma: charge each cma heap's dmem Message-ID: References: <20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2@redhat.com> <20260218-dmabuf-heap-cma-dmem-v2-3-b249886fb7b2@redhat.com> <435330fd-ecdd-43c7-8527-f285c03c6421@amd.com> <0ff02d77-13e8-4b2c-b714-38037595d535@amd.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0ff02d77-13e8-4b2c-b714-38037595d535@amd.com> On Fri, Feb 20, 2026 at 09:16:15AM +0100, Christian König wrote: > On 2/19/26 18:10, Eric Chanudet wrote: > > On Thu, Feb 19, 2026 at 08:17:28AM +0100, Christian König wrote: > >> > >> > >> On 2/18/26 18:14, Eric Chanudet wrote: > >>> The cma dma-buf heaps let userspace allocate buffers in CMA regions > >>> without enforcing limits. Since each cma region registers in dmem, > >>> charge against it when allocating a buffer in a cma heap. > >>> > >>> Signed-off-by: Eric Chanudet > >>> --- > >>> drivers/dma-buf/heaps/cma_heap.c | 15 ++++++++++++++- > >>> 1 file changed, 14 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > >>> index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..bbd4f9495808da19256d97bd6a4dca3e1b0a30a0 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" > >>> > >>> @@ -58,6 +59,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 +278,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 +322,17 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, > >>> if (align > CONFIG_CMA_ALIGNMENT) > >>> align = CONFIG_CMA_ALIGNMENT; > >>> > >>> + if (mem_accounting) { > >> > >> Since mem_accounting is a module parameter it is possible to make it changeable during runtime. > >> > >> IIRC it currently is read only, but maybe add a one line comment that the cma heap now depends on that. > >> > > > > Agreed, while read-only it is easily missed without at least a comment. > > Alternatively, should that value be captured in the init callback to > > guaranty it is set once and make this requirement clearer? > > It probably makes more sense to make nails with heads and make it runtime configurable. > > I'm not sure how exactly dmem_cgroup_try_charge()/dmem_cgroup_uncharge() works, could be that it works correctly out of the box and you just need to initialize buffer->pool to NULL when mem_accounting is not enabled. > dmem_cgroup_uncharge() is called unconditionally and checks for NULL while buffer is kzalloc(), so buffer->pool is NULL from cma_heap_allocate() if mem_accounting is not set. Some buffers will be accounted for and some won't depending on when it's toggled and when buffers are requested, which didn't seem to serve much use and is why it's set read-only. > Regards, > Christian. > > > > > Thanks, > > > >> Apart from that the series looks totally sane to me. > >> > >> Regards, > >> Christian. > >> > >>> + ret = dmem_cgroup_try_charge( > >>> + cma_get_dmem_cgroup_region(cma_heap->cma), 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 +387,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); > >>> free_buffer: > >>> kfree(buffer); > >>> > >>> > >> > > > -- Eric Chanudet