From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5A8CAC52D71 for ; Wed, 7 Aug 2024 13:59:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=l4tkSTJ3d3BSGMNwGHhQB4Np/iPXkKocLDFP/6ICNFI=; b=SvxbgAcafqqUCy7oRQlwbtbstO UmDzKHh6nuKNSTNXQ6rShh++1Lc7lszpZx5Q/CMVqysoUpLyam1DdXD4V+hUGXgb2MVqBfjqLZ+7w 7OobKZV6fJuu5AiK1jL3X3WZTuQvU1lWhplg3HFFJT3CRr8PI+SqNPFATUXc69cJaZfgHC6exec2W OVGnnwk8X2E9XmALHX992c5oudpGU2QdgFon5p5ioqVQXCGvDd+9XGfHr2xtbYZi0pxwG3zQP2dNB uvFnMHR0z6qLxfR0SFP2di7r7DJ/n+T7O58DJmeqZotw3Lp2cjg6Hd4ME3lCd63L5OJoEp31wCOAi MaGT6bIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbhCT-00000005F7u-3aj8; Wed, 07 Aug 2024 13:59:37 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbhBn-00000005EsP-0Our for linux-arm-kernel@lists.infradead.org; Wed, 07 Aug 2024 13:58:56 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0E6D161007; Wed, 7 Aug 2024 13:58:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 555DAC32781; Wed, 7 Aug 2024 13:58:51 +0000 (UTC) Date: Wed, 7 Aug 2024 14:58:49 +0100 From: Catalin Marinas To: Robin Murphy Cc: Baruch Siach , Christoph Hellwig , Marek Szyprowski , Will Deacon , iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Petr =?utf-8?B?VGVzYcWZw61r?= , Ramon Fried , Elad Nachman Subject: Re: [PATCH v5 1/3] dma: improve DMA zone selection Message-ID: References: <5200f289af1a9b80dfd329b6ed3d54e1d4a02876.1722578375.git.baruch@tkos.co.il> <8230985e-1581-411f-895c-b49065234520@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8230985e-1581-411f-895c-b49065234520@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240807_065855_234060_4934C09C X-CRM114-Status: GOOD ( 15.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Thanks Robin for having a look. On Wed, Aug 07, 2024 at 02:13:06PM +0100, Robin Murphy wrote: > On 2024-08-02 7:03 am, Baruch Siach wrote: > > When device DMA limit does not fit in DMA32 zone it should use DMA zone, > > even when DMA zone is stricter than needed. > > > > Same goes for devices that can't allocate from the entire normal zone. > > Limit to DMA32 in that case. > > Per the bot report this only works for CONFIG_ARCH_KEEP_MEMBLOCK, Yeah, I just noticed. > however > the whole concept looks wrong anyway. The logic here is that we're only > forcing a particular zone if there's *no* chance of the higher zone being > usable. For example, ignoring offsets for simplicity, if we have a 40-bit > DMA mask then we *do* want to initially try allocating from ZONE_NORMAL even > if max_pfn is above 40 bits, since we still might get a usable allocation > from between 32 and 40 bits, and if we don't, then we'll fall back to > retrying from the DMA zone(s) anyway. Ah, I did not read the code further down in __dma_direct_alloc_pages(), it does fall back to a GFP_DMA allocation if !dma_coherent_ok(). Similarly with swiotlb_alloc_tlb(), it keeps retrying until the allocation fails. So yes, this patch can be dropped. -- Catalin