From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) (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 90B55496D40; Tue, 15 Sep 2026 11:20:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789471263; cv=none; b=u1HTioQniOhhK6Cq6qU7jq6fEeo3GOJ5QzcDA2xaCDHDh3Psm1ORf4m3XdJjwiuncWUiw1oDP6Jkg1rp4LJKBzM0gmuB/qlQyzMkrlk8ANvm3xNbkA4e90yX0ycSF93P+1OJ9lomOt96CpnPFOKO7MVnPwdnciartI4FXLWjZxA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789471263; c=relaxed/simple; bh=uqIgqIxz2MYxpYQY//sxZKjBZmFrVGjSYU/hzUgktt4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kn0jYsxcmBx8J6Vd/rRrvKCmmyfRI03Ld+gH4tNOmB0PpgcLVTS7uwWI/eUEN7bpij8ner5NslXXPWM75OQoP2wP3MBo0bh38JPnxkiTfm4B6Unt4UlDBboDp30jNRglKpuSHDhSeBp3kBNBwYVAcZx/CFnq3LBK2icK4ZEevks= 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=yme4vGVo; arc=none smtp.client-ip=115.124.30.99 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="yme4vGVo" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1789471257; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=pJ9Rr9CykAOIDKHJD/CzvfpeB8yYEsova679wlOFG74=; b=yme4vGVoBl2QGh6JGypvXCT/Iw9Ib3fYE/4s01F1tDF6W/hVHqtSVG375BSZ/go8Dx4q4SdZcf44P7yYiEhOjmKs0w8NekmrxnXTbUldjGCFarrXd94kpvqaDl0f+97sK7G1ehLKsU4RqKkHTvMt2xxOjLAhOHyhKmuUBfCMMkk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=xiangzao@linux.alibaba.com;NM=1;PH=DS;RN=19;SR=0;TI=SMTPD_---0XB1X-IG_1789471237; Received: from banye.tbsite.net(mailfrom:xiangzao@linux.alibaba.com fp:SMTPD_---0XB1X-IG_1789471237 cluster:ay36) by smtp.aliyun-inc.com; Tue, 15 Sep 2026 19:20:56 +0800 From: Yuanhe Shu To: Kiryl Shutsemau , Will Deacon , Robin Murphy , Joerg Roedel , Nicolin Chen Cc: Jason Gunthorpe , Pranjal Shrivastava , Mostafa Saleh , Thierry Reding , Krishna Reddy , Jonathan Hunter , Breno Leitao , Kyle McMartin , Usama Arif , kernel-team@meta.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 2/2] iommu/arm-smmu-v3: Default queue depths to one page in a kdump kernel Date: Tue, 15 Sep 2026 19:20:36 +0800 Message-ID: <20260915112037.1495272-1-xiangzao@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260909095228.2174031-3-kas@kernel.org> References: <20260909095228.2174031-1-kas@kernel.org> <20260909095228.2174031-3-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Tested-by: Yuanhe Shu We hit the same problem on our arm64 platform: the kdump capture kernel runs out of memory because the SMMUv3 queues are still allocated at full hardware size. We had started looking into it ourselves, then came across this series, so we tested it on the affected hardware rather than prepare a duplicate fix. It resolves the problem for us - details below. Test platform: an arm64 server, 128 cores, 2 NUMA nodes, 512 GiB RAM, exposing 6 SMMUv3 instances. 64K-page kernel (PAGE_SHIFT=16) based on Linux 7.0.14 with the series applied on top; crashkernel reservation is 512 MiB. On this platform kdump FAILS without the patch, and the series fixes it. Before - capture kernel WITHOUT the series: All 6 SMMUv3 instances still allocate the hardware-maximum queues: arm-smmu-v3 arm-smmu-v3.0.auto: allocated 524288 entries for cmdq arm-smmu-v3 arm-smmu-v3.0.auto: allocated 524288 entries for evtq arm-smmu-v3 arm-smmu-v3.0.auto: allocated 524288 entries for priq (... same for all 6 instances) That is 8 + 16 + 8 = 32 MiB per instance, 192 MiB total - 37.5% of the 512 MiB reservation. The capture kernel OOMs before makedumpfile runs: swapper/0 invoked oom-killer: gfp_mask=0x2040cc0(GFP_KERNEL|...), order=0 Out of memory and no killable processes... Rebooting in 10 seconds.. => no vmcore is saved. After - capture kernel WITH the series: All three queues are floored to one page per instance: arm-smmu-v3 arm-smmu-v3.0.auto: allocated 4096 entries for cmdq arm-smmu-v3 arm-smmu-v3.0.auto: allocated 2048 entries for evtq arm-smmu-v3 arm-smmu-v3.0.auto: allocated 4096 entries for priq (... same for all 6 instances) => ~1.1 MiB total (~191 MiB freed). All 6 instances re-probe cleanly (no -ENXIO, no allocation failure) and a 608 MB vmcore is saved. Same machine, same 512 MiB reservation; the only difference is the v6 series, so this is a controlled before/after. Thanks, Yuanhe