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 4F69130F80F for ; Tue, 13 Jan 2026 16:14:50 +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=1768320892; cv=none; b=pS/JDkNwsFqeqbG6i7B5jlMfMgeJinn5vqT1pUEKWUwJk+NB7EbaGHFYNBiXtORV3l6PLSNkR07KgnmUv4RsxqYizKA6oHaEPzQXP3YJokvOX6HiyAmtTuW4vJ4JtFH7nYGiuxBgdPC9PB7hFZZnsxjFVDDWMgSSH9qqeRWON5g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768320892; c=relaxed/simple; bh=apLmA7rSnQW0nA/la7Vdbnq+2B7JRePyYXnflGb/e3E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MPGPn1BIAQie1pLfmuaYkyOmFrBB6n4cr7bBIFGsDSLe2JjbBOKEIkXmdDOsnLZqfqBXafmZuIkC9Q9woLwqkffwMOx1d29LObtaw/0bK6WU3A9e3kcPkHruRyPfcNi2Ejf26q4AgZy7Iho3WdbsiIwkr0Ugtm/P0IBpvvvo34c= 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 B9226497; Tue, 13 Jan 2026 08:14:42 -0800 (PST) Received: from [10.57.46.249] (unknown [10.57.46.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 900693F59E; Tue, 13 Jan 2026 08:14:46 -0800 (PST) Message-ID: <8d0c7b1c-fc12-4498-acbb-eaf6cab9ef3f@arm.com> Date: Tue, 13 Jan 2026 16:14:44 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] dma/pool: Avoid allocating redundant pools To: Baoquan He Cc: m.szyprowski@samsung.com, akpm@linux-foundation.org, vbabka@suse.cz, david@kernel.org, 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 References: <8ab8d8a620dee0109f33f5cb63d6bfeed35aac37.1768230104.git.robin.murphy@arm.com> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-01-13 10:16 am, Baoquan He wrote: > On 01/12/26 at 03:46pm, Robin Murphy wrote: >> On smaller systems, e.g. embedded arm64, it is common for all memory >> to end up in ZONE_DMA32 or even ZONE_DMA. In such cases it is redundant > > This is true and the whole series looks great to me. Do we need adjust > warn_alloc() to handle empty DMA32 zone too like empty DMA zone case? Hmm, I'd be inclined to think that if nobody's complaining already then we can probably just leave it as-is. A GFP_DMA32 allocation won't OOM unless *both* ZONE_DMA32 and ZONE_DMA are empty, right? At that point I'd imagine it's a bit more significant if someone who wants DMA32 memory can't have any - don't we have a mechanism for reserving some "low" memory for kdump for pretty much this exact reason? A special case for when ZONE_DMA is tiny such that GFP_DMA can be expected to fail often seems fair, but in general I'd expect that if GFP_DMA32 starts failing then it's more a sign of a genuine mismatch between the kernel's expectations and the system configuration. Thanks, Robin. >> to allocate a nominal pool for an empty higher zone that just ends up >> coming from a lower zone that should already have its own pool anyway. >> We already have logic to skip allocating a ZONE_DMA pool when that is >> empty, so generalise that to save memory in the case of other zones too. >> >> Signed-off-by: Robin Murphy >> --- >> kernel/dma/pool.c | 19 ++++++++++++++----- >> 1 file changed, 14 insertions(+), 5 deletions(-) >> >> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c >> index 2645cfb5718b..c5da29ad010c 100644 >> --- a/kernel/dma/pool.c >> +++ b/kernel/dma/pool.c >> @@ -184,6 +184,12 @@ static __init struct gen_pool *__dma_atomic_pool_init(size_t pool_size, >> return pool; >> } >> >> +#ifdef CONFIG_ZONE_DMA32 >> +#define has_managed_dma32 has_managed_zone(ZONE_DMA32) >> +#else >> +#define has_managed_dma32 false >> +#endif >> + >> static int __init dma_atomic_pool_init(void) >> { >> int ret = 0; >> @@ -199,17 +205,20 @@ static int __init dma_atomic_pool_init(void) >> } >> INIT_WORK(&atomic_pool_work, atomic_pool_work_fn); >> >> - atomic_pool_kernel = __dma_atomic_pool_init(atomic_pool_size, >> + /* All memory might be in the DMA zone(s) to begin with */ >> + if (has_managed_zone(ZONE_NORMAL)) { >> + atomic_pool_kernel = __dma_atomic_pool_init(atomic_pool_size, >> GFP_KERNEL); >> - if (!atomic_pool_kernel) >> - ret = -ENOMEM; >> + if (!atomic_pool_kernel) >> + ret = -ENOMEM; >> + } >> if (has_managed_dma()) { >> atomic_pool_dma = __dma_atomic_pool_init(atomic_pool_size, >> GFP_KERNEL | GFP_DMA); >> if (!atomic_pool_dma) >> ret = -ENOMEM; >> } >> - if (IS_ENABLED(CONFIG_ZONE_DMA32)) { >> + if (has_managed_dma32) { >> atomic_pool_dma32 = __dma_atomic_pool_init(atomic_pool_size, >> GFP_KERNEL | GFP_DMA32); >> if (!atomic_pool_dma32) >> @@ -228,7 +237,7 @@ static inline struct gen_pool *dma_guess_pool(struct gen_pool *prev, gfp_t gfp) >> return atomic_pool_dma ?: atomic_pool_dma32 ?: atomic_pool_kernel; >> if (gfp & GFP_DMA32) >> return atomic_pool_dma32 ?: atomic_pool_dma ?: atomic_pool_kernel; >> - return atomic_pool_kernel; >> + return atomic_pool_kernel ?: atomic_pool_dma32 ?: atomic_pool_dma; >> } >> if (prev == atomic_pool_kernel) >> return atomic_pool_dma32 ? atomic_pool_dma32 : atomic_pool_dma; >> -- >> 2.34.1 >> >> >