From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 B77D1163 for ; Wed, 14 Jan 2026 02:05:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768356333; cv=none; b=Tl34eHWeLanSNy87rfVjXqEZ3TvOL7cJ023tZwwpfzDYFhus+KSmwIWS9hGzsOcmrOBUENwQwLuGmq9siobgpusxnHcAu9bGOkAn3jHEx7q1B2bZYgUvzrBcmtXLIcaLj36ihilJoq5yHa6n/ubjDOTziFSflpRFz42Fuk4/YI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768356333; c=relaxed/simple; bh=A3sKE909XRoB258WRS9EZsUWiMgvVzaObpjPCRf8FNo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b0YJIH+r/6w1A9A0Od/0clNl063F8DpZkRGNLZ5ppMTCc9YtY3lsK5sC23ZSfKdU0qCZiQmpNkurcmouXSntyf3lOkB2tc2WECgKddVNK3Dj7scCQXt2Q0d3yjjQ7byOh3s85CEkcyQAK3SaxYovCeZqFY54ozoFUw4etRurvtw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LBk3cDWG; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LBk3cDWG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768356330; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5jrzCY4RhpuK7plFMFlkVNnwXkq9N4udgNExDYEdqkM=; b=LBk3cDWGqzVDhPbecuqnRf/AB5zj1MOfv21bBuR/WauhtlMdnHA14Ac3/rbEVr2cvhjYHH gWKcpDA0SkbIIn0A/qKYSeiQxIBw1VLnhk2odk16mZIBwU47OJ5Kl3OV9k6veSXXwytZrb wRlWPp8CTCMzpCIDAZN/a+ntBYTlWjE= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-173-I-UtY7Y4MUaHIAbGIClX1g-1; Tue, 13 Jan 2026 21:05:25 -0500 X-MC-Unique: I-UtY7Y4MUaHIAbGIClX1g-1 X-Mimecast-MFC-AGG-ID: I-UtY7Y4MUaHIAbGIClX1g_1768356322 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D822518003FC; Wed, 14 Jan 2026 02:05:21 +0000 (UTC) Received: from localhost (unknown [10.72.112.63]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 03A0B19560A2; Wed, 14 Jan 2026 02:05:19 +0000 (UTC) Date: Wed, 14 Jan 2026 10:05:10 +0800 From: Baoquan He To: Robin Murphy 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 Subject: Re: [PATCH 3/3] dma/pool: Avoid allocating redundant pools Message-ID: References: <8ab8d8a620dee0109f33f5cb63d6bfeed35aac37.1768230104.git.robin.murphy@arm.com> <8d0c7b1c-fc12-4498-acbb-eaf6cab9ef3f@arm.com> 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: <8d0c7b1c-fc12-4498-acbb-eaf6cab9ef3f@arm.com> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On 01/13/26 at 04:14pm, Robin Murphy wrote: > 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. Makes sense to me. I remember someone plans to take off both DMA and DMA32 zone in linux kernel, but that might not happen soon.