From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8C4E43624CE for ; Mon, 12 Jan 2026 15:46:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768232810; cv=none; b=fUiVh8br9IZrVkGwgbUWJL58vuBFSCZb2een9F3RRP7fnJwq8HtrdbgJxJetoz1Mz52NsNRDqQZzoq4HSiLClD5vxW06Q1ArdfYSELWiSlviLoN4ko4hrlFV39WKWrd2swxUScDw0PyPi/yPTI+poz/ohe0KA0gQ8BFhUEkIEr4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768232810; c=relaxed/simple; bh=pdD/IDl0UPstq2KqVssQVCdfjH7UYtSHujkw5ToSFAg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=HKP2zX4CpcLeVqY++43cVlj5ICpW5d5RILNC//J9l+uhfJJMvE7xq4wa6uOBOOVRn9UZrfZJYN/y4LboOIbug3fnEOcLWh/lvGLzmEPccipwGqUaXbeTzk61zZaQJsCLiGFnD7u2bUMI0A8GyZ/TjvK5TdtVX5RztXifZ99CR78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 73310497; Mon, 12 Jan 2026 07:46:39 -0800 (PST) Received: from 010265703453.arm.com (unknown [10.57.48.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B7BFF3F694; Mon, 12 Jan 2026 07:46:43 -0800 (PST) From: Robin Murphy To: m.szyprowski@samsung.com, akpm@linux-foundation.org, vbabka@suse.cz, david@kernel.org Cc: bhe@redhat.com, iommu@lists.linux-foundation.org, linux-mm@kvack.org, vladimir.kondratiev@mobileye.com, s-adivi@ti.com, linux-kernel@vger.kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com Subject: [PATCH 0/3] dma-mapping: Improve atomic pool behaviour Date: Mon, 12 Jan 2026 15:46:35 +0000 Message-Id: X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, These days we have somewhat of a matrix of mm zones that may or may not exist and may or may not be empty, which the per-zone atomic pool logic doesn't actually handle all that well. It's not all that difficult to improve robustness and reduce redundancy, so that's what this series aims for. I initially wrote this just because I happened to be looking through the boot log of one of my boards and had one of those out-of-the-blue realisations of "hang on, why *is* it allocating pools for zones it doesn't even have memory in?", but coincidentally, it seems that others happened to notice related aspects around the same time[1][2]. This is my attempt to sort it all out properly. I guess this could go via either the dma-mapping or mm tree, whichever maintainers prefer. Thanks, Robin. [1] https://lore.kernel.org/linux-iommu/20260112065857.3137331-1-vladimir.kondratiev@mobileye.com/ [2] https://lore.kernel.org/linux-iommu/20260112104749.4132641-1-s-adivi@ti.com/ Robin Murphy (3): dma/pool: Improve pool lookup mm_zone: Generalise has_managed_dma() dma/pool: Avoid allocating redundant pools include/linux/mmzone.h | 9 +++++---- kernel/dma/pool.c | 27 ++++++++++++++++++--------- mm/page_alloc.c | 8 ++------ 3 files changed, 25 insertions(+), 19 deletions(-) -- 2.34.1