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 X-Spam-Level: X-Spam-Status: No, score=-12.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DD5BC433E6 for ; Fri, 28 Aug 2020 17:45:13 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CC8F12074A for ; Fri, 28 Aug 2020 17:45:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xtuwWhla" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC8F12074A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gimrnhcZGrMAeDa9S/3kWaD7f55U/spzlYb+POgxlBU=; b=xtuwWhlaQCJxah4/n3e5ks4BV dy8MfY3LE00QZckqLI9UBAj3+Uc1uQTMKTOlFDPcrhpSLfcpVDpIzKMIPq/BfApHkvk5h2vSbW6Rz ChypjaEKk4aILwyt+6J/ZRU0nBMJrN7fQhwY3PnMzkHRGa3SxzR+LO0MNM7JvKbhT//JPZLnjUop3 DUB9cYNeRIiYBTKn0yTKSNyHKndgxOFRumrmECLeGAYQsrRiYlOKW7bjyiFpJdUo6fnOhHNwFL7IM QS9ABHFPygGBfC7NjaWmqAX/oNE3mUlKjsKSq6ddBC4YXd+T+c0/I20KNwb0MoiRAID7fKEYKvwAq jgBagzfUQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBiPi-0001Jj-5R; Fri, 28 Aug 2020 17:43:46 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBiPg-0001J5-2X; Fri, 28 Aug 2020 17:43:44 +0000 Received: from gaia (unknown [46.69.195.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EDB422074A; Fri, 28 Aug 2020 17:43:41 +0000 (UTC) Date: Fri, 28 Aug 2020 18:43:39 +0100 From: Catalin Marinas To: Nicolas Saenz Julienne Subject: Re: [RFC] arm64: mm: Do not use both DMA zones when 30-bit address space unavailable Message-ID: <20200828174338.GK3169@gaia> References: <20200819182434.28196-1-nsaenzjulienne@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200819182434.28196-1-nsaenzjulienne@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200828_134344_202371_E0AA9B33 X-CRM114-Status: GOOD ( 25.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: robh@kernel.org, f.fainelli@gmail.com, linux-kernel@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, Will Deacon , hch@lst.de, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Nicolas, On Wed, Aug 19, 2020 at 08:24:33PM +0200, Nicolas Saenz Julienne wrote: > There is no benefit in splitting the 32-bit address space into two > distinct DMA zones when the 30-bit address space isn't even available on > a device. If that is the case, default to one big ZONE_DMA spanning the > whole 32-bit address space. > > This will help reduce some of the issues we've seen with big crash > kernel allocations. > > Signed-off-by: Nicolas Saenz Julienne > --- > > Whith this patch, on a 8GB RPi4 the setup looks like this: > > DMA [mem 0x0000000000000000-0x000000003fffffff] > DMA32 [mem 0x0000000040000000-0x00000000ffffffff] > Normal [mem 0x0000000100000000-0x00000001ffffffff] > > And stock 8GB virtme/qemu: > > DMA [mem 0x0000000040000000-0x00000000ffffffff] > DMA32 empty > Normal [mem 0x0000000100000000-0x000000023fffffff] > > arch/arm64/mm/init.c | 29 +++++++++++++++++++++++++---- > 1 file changed, 25 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index b6881d61b818..857a62611d7a 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -183,13 +183,20 @@ static void __init reserve_elfcorehdr(void) > > /* > * Return the maximum physical address for a zone with a given address size > - * limit. It currently assumes that for memory starting above 4G, 32-bit > - * devices will use a DMA offset. > + * limit or zero if memory starts from an address higher than the zone targeted. > + * It currently assumes that for memory starting above 4G, 32-bit devices will > + * use a DMA offset. > */ > static phys_addr_t __init max_zone_phys(unsigned int zone_bits) > { > - phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, zone_bits); > - return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM()); > + phys_addr_t base = memblock_start_of_DRAM(); > + phys_addr_t offset = base & GENMASK_ULL(63, 32); > + s64 zone_size = (1ULL << zone_bits) - (base & DMA_BIT_MASK(32)); > + > + if (zone_size <= 0) > + return 0; > + > + return min(base + zone_size + offset, memblock_end_of_DRAM()); > } OK, so we can still get some ZONE_DMA if DRAM starts in the first GB. I don't think it entirely solves the problem. It just happens that the other affected SoCs don't have memory in the first GB. With this patch, we go by the assumption that ZONE_DMA/DMA32 split is only needed if there is memory in the low 1GB and such <32-bit devices don't have a DMA offset. Adding Rob H (it's easier to ask him than grep'ing the DT files ;)), we may be ok with this assumption on current SoCs. An alternative (and I think we had a patch at some point) is to make it generic and parse the dma-range in the DT to identify the minimum mask and set ZONE_DMA accordingly. But this doesn't solve ACPI, so if Linux can boot with ACPI on RPi4 it would still be broken. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel