From nobody Wed Jun 17 06:11:26 2026 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 0FAE43E1216 for ; Thu, 23 Apr 2026 09:52:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776937982; cv=none; b=n9ClXe1Rt2MkStrCqmhjcYubxGM0YhLiHgMfS0kKOuBzTXY/k0KMCi7KbIBonlfnRd7wEDU5gUWbmhQVkr9J3ebr0CEOEgxGlH+JulSTRBg2H0FVj/8mQf5aoztzI3HmQuq19DNW+uyx5l1Okq5Co+7Ky/jtiU+g1tW6D1654Bg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776937982; c=relaxed/simple; bh=14aLCO5GWoojNsXtLkEGVdnhp/kzZ28H3YHxv0pj090=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=cSJJOgd3CBy/eejM5orDnyV1deZe+kyYGK0ycROjzqXuT2RG0e/Lz1SiVaMalnCt6USKpmcQPLeLPNEJmCOzticEfQgBW48oWOEs5LdA1iBp9Mw6+m+yMj9wUkMOucHhDzHOWTl2X6wiNYF0uBfJHwl57roQnIbPZ+bIi1DQpK0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=xQMNn3W+; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="xQMNn3W+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776937965; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=A6YdoIxeuZkdXGNum/CTyuM6cy/pazqB/L6iHJ0FGmU=; b=xQMNn3W+JKPZ3MP6p92sA5/ZxtywbTM3HGNs/VpeFiXmC8dKy+BvMeU0iasU+TMdfBkxGSzR7NTSgIRGkURQdPUxmLwEGRuUV4JDC1EM9JgK64zFNkTIk9rimVYK5HV7RWjiPvTmTkLXu5wrWg/OePu1Z+Q/Z134NQSmTHPxsmA= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X1ZJOkg_1776937964; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X1ZJOkg_1776937964 cluster:ay36) by smtp.aliyun-inc.com; Thu, 23 Apr 2026 17:52:44 +0800 From: Feng Tang To: Marek Szyprowski , Robin Murphy , Ying Huang , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: Christoph Hellwig , Catalin Marinas , Will Deacon , Feng Tang Subject: [PATCH v2] dma-contiguous: setup default pernuma cma area if not configured explicitly Date: Thu, 23 Apr 2026 17:52:43 +0800 Message-Id: <20260423095243.14239-1-feng.tang@linux.alibaba.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There was a report on a multi-numa-nodes ARM server that when IOMMU is disabled, the dma_alloc_coherent() function always returns memory from node 0 even for devices attaching to other nodes, while they can get local dma memory when IOMMU is on with the same API. The reason is, when IOMMU is disabled, the dma_alloc_coherent() will go the direct way and call dma_alloc_contiguous(). The system doesn't have any explicit cma setting (like per-numa cma), and only has a default 64MB cma reserved area (on node 0), where kernel will try first to allocate memory from. Robin Murphy suggested to setup pernuma cma or disable cma, which did solve the issue. While there is still concern that for customers which don't have much kernel knowledge, they could still suffer from this silently as some architectures enable cma area by default (not an issue for X86 though, which set CONFIG_CMA_SIZE_MBYTES to 0 by default) for most Linux distributions.=20 One thought is to follow the current cma reserving policy for platform with 'CONFIG_DMA_NUMA_CMA=3Dy', that if the numa cma is not explicitly configured, set it up according to CONFIG_CMA_SIZE_MBYTES (The percentage kernel option is not considered yet as the number of NUMA nodes could be big). Suggested-by: Ying Huang Signed-off-by: Feng Tang --- Changelog: since v1 * don't use the original way of adding alloc_pages_node() before trying default cma node (Robin Murphy) kernel/dma/contiguous.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index c56004d314dc..b2fd6789db85 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -107,6 +107,7 @@ static struct cma *dma_contiguous_numa_area[MAX_NUMNODE= S]; static phys_addr_t numa_cma_size[MAX_NUMNODES] __initdata; static struct cma *dma_contiguous_pernuma_area[MAX_NUMNODES]; static phys_addr_t pernuma_size_bytes __initdata; +static bool numa_cma_configured; =20 static int __init early_numa_cma(char *p) { @@ -135,6 +136,7 @@ static int __init early_numa_cma(char *p) break; } =20 + numa_cma_configured =3D true; return 0; } early_param("numa_cma", early_numa_cma); @@ -142,6 +144,7 @@ early_param("numa_cma", early_numa_cma); static int __init early_cma_pernuma(char *p) { pernuma_size_bytes =3D memparse(p, &p); + numa_cma_configured =3D true; return 0; } early_param("cma_pernuma", early_cma_pernuma); @@ -181,6 +184,9 @@ static void __init dma_numa_cma_reserve(void) continue; } =20 + if (!numa_cma_configured) + pernuma_size_bytes =3D size_bytes; + if (pernuma_size_bytes) { =20 cma =3D &dma_contiguous_pernuma_area[nid]; --=20 2.43.5