From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43EB83161BE for ; Thu, 2 Jul 2026 20:25:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783023931; cv=none; b=ty6eehrTUVNUIERDNm3iktblHM12AYfpV/5QPDs26tEDul//lfak6yFeM7ikhbS9RkFkVae11RrMVfZ8VaWwh3h+hRHByhCJBEwSV3aNXH/Sw14EzLMTOL9kxeYmMNMZ1/ZRW4sv8zciYUEgJP2yVtA1ah/QAecvFQgLhNvP/Ps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783023931; c=relaxed/simple; bh=k0pMqimW5JNY6E7Ta2qKbyunsX9A3EiSLwuDAUjF0Bc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jpW3wdJUfmdGTfE+xRJml66qhY+8Cwa7rCznqOfRPE+q+ODGQ+FYARFhZm7Uo082FZlD18365NKyHLbDT6aSyx+awoU4uVzYB23HozOzL/nUnTFpz9Kj+y3DFwCcrrbLXhlvgT+w4I9lRZM8BX/fO/vvxg2e5YosE/ZzF8Lnj7g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NABdxQmC; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NABdxQmC" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2c81db32393so256265ad.0 for ; Thu, 02 Jul 2026 13:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783023929; x=1783628729; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=D1/4TQCQv4x02z/PLYtJPpvADBvf6W/GQerzpdxNkZY=; b=NABdxQmClwq5TW5ZW6Q6ZtCMk9BWSPNASRBa/Qe9/I5TAgHt3KZM/Om5PyIs1Ahkku +awun+Hm4fhSDLvfYq9R13diiUxPMF/13gkLEE67PNcZ2TJ2VEnRSma504viXz+oTdmx Nr7tq56hsGrX+4tw3OBtqSjoX8BN7W0E+1HKi8iM5bRQ+rZnoh52mm3Bh682kqdVjWTd y7qauCAylpi4gX9PTH0KJd7TLSxDjOeNzZHWXgFGPYkcoodu88GmtxdSljr1h6FhAIhV NFKws8Ku2Ko7rA4zA7grAf+xRPyNSroV5qqZ0MBPF20XjhQ58R9GlHJ5mUiAAyyq3E96 Qxog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783023929; x=1783628729; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=D1/4TQCQv4x02z/PLYtJPpvADBvf6W/GQerzpdxNkZY=; b=Q3P8sDJD91n/pHO5/iRphjbf/BWbbVhsaxINVDxLRWxl4oK7NevTm/NDjMWYBHbxJT gpqKf6csiXLzk/S/YZdS0xo5ab3MMSVwcfRwFXGv7LfzEdg2BbPO7uuSq1rP40MBJcxn 6rYnS5yBffjEyW8qYJMFCSaXxAdygaZt0A5ErHWqOONjGPBVwHnCJTch9e8rHyrORXCJ +UlwhC4FfzPmDu1FWLws0qvqgRI036vIdWsYHB3Mp/1Op+egRLQAoQMsuVP7f0UgND2G i1elDZwDoFJ2nSXUssIArFoCCp7mwj3uis46QNh/tieHsOOsTSlB/vzHWHqQW+SOtMaA NakA== X-Forwarded-Encrypted: i=1; AHgh+RoRIYiEh1vRhuzv5+wGK25FUjSHfJAQqW+3VkzAKT/OIpazORfEcu2BgnJAoIzcJe/LaAhKe2ugjyI+MxU=@vger.kernel.org X-Gm-Message-State: AOJu0YxKX+FI3FbaHIi9NMYlhcM02C12EjqEX8HnOYZ1b6MgKgfdYAor VK57RmZNItk2k5YzpWpqzIDrhlwmqiIkGYkXRpR80xB/JQqs4Jx/5kMP9xND2wYgqg== X-Gm-Gg: AfdE7cmw+ZGITMInL8jOJgJQwoC88DyHp95JQ7K09zOocH0R3UctkeRM33Ay+LDzE6M CgWNxnh2ojQbNpQr/udhTT2ri5J/HktsnDu1Vh4KmZm7pUVWrUf2LvvvEJt0Mhwwo/rihRv1daZ BGqoi9VKx3u4kz3QtGi87SwpnN8NlY+ePNIyNh/qVKMNwTI+bsml/Yr6o/BrJ9eubEk+IxBi766 OJqrOaKv42Wlq4OqJff/jM34UrsVQNpMqUheyhLXYmAVf1yGX/Rkq+sj3wa9OJkqgbJRcm5OuVw 8U3TtP1Pgp75anmI75iLns2gn6BNmq1fDlkupuc1sGJKMm5LuNJ38qYfZudjKNG6/2eixyfqXQD +XswDNGSZyNJEqwGQ0J0oEbNpylOeoRg51revvxh4p+4UjtMmUHhNjYhEjeth25mRjYowKClfln /JKVHIN/q1p4f0nrx4pVCRPqIxEmGLfUYXFdkeCXYsN/0HGsA= X-Received: by 2002:a17:902:da8e:b0:2bf:1000:d3ac with SMTP id d9443c01a7336-2caa6ff1431mr2958025ad.11.1783023928961; Thu, 02 Jul 2026 13:25:28 -0700 (PDT) Received: from google.com (10.129.124.34.bc.googleusercontent.com. [34.124.129.10]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ca9aa0b7e9sm18461795ad.81.2026.07.02.13.25.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2026 13:25:27 -0700 (PDT) Date: Thu, 2 Jul 2026 20:25:21 +0000 From: Pranjal Shrivastava To: Kiryl Shutsemau Cc: Will Deacon , Robin Murphy , Joerg Roedel , Jason Gunthorpe , Nicolin Chen , Kyle McMartin , Breno Leitao , Usama Arif , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel Message-ID: References: <20260702112825.781750-1-kas@kernel.org> 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: On Thu, Jul 02, 2026 at 04:38:55PM +0100, Kiryl Shutsemau wrote: > On Thu, Jul 02, 2026 at 03:05:12PM +0000, Pranjal Shrivastava wrote: > > On Thu, Jul 02, 2026 at 12:28:25PM +0100, Kiryl Shutsemau (Meta) wrote: > > > The command, event and PRI queues are sized from the maxima the hardware > > > > A minor note here is PRI & EVT queues are disabled for the kdump kernel > > (see arm_smmu_device_reset). We could just mention all SMMU queues are > > sized [...] in the commit message. > > Fair enough. > > Here's updated commit message (I will send v3 in few days, if no new > feedback): > > Subject: [PATCH v3] iommu/arm-smmu-v3: Shrink command/event/PRI queues in > kdump kernel > > All SMMU queues are sized from the maxima the hardware advertises in IDR1, > which can be several megabytes each, and are allocated at probe. The kdump > kernel already disables the event and PRI queues (arm_smmu_device_reset() > drops CR0_EVTQEN/CR0_PRIQEN) but still allocates them at full size. On > systems with many SMMUv3 instances that cost is paid per instance and adds > up to tens of megabytes of coherent DMA in the capture kernel. > > A kdump capture kernel runs from a small crashkernel reservation and only > has to drive the few devices used to save the dump, so deep queues serve > no purpose. The queues are not on the DMA data path, so dump throughput is > unaffected; a shallower command queue only bounds how many commands may be > in flight before a sync, which does not matter for the capture kernel's > small device count and modest I/O. > > Clamp every queue to a single page when is_kdump_kernel() is true. Doing > it in arm_smmu_init_one_queue() covers the command, event and PRI queues > in one place. The command queue still holds at least one batch plus a sync > (256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so > command batching keeps working. > Looks good. Thanks! Praan