From patchwork Wed Aug 19 18:24:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Saenz Julienne X-Patchwork-Id: 11724839 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 30D9F618 for ; Wed, 19 Aug 2020 18:25:06 +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 05B4620758 for ; Wed, 19 Aug 2020 18:25:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nYoKANQj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05B4620758 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.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:MIME-Version:Message-Id:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=XLTrWrWsj+KNognoYAF0ZrZjgQyGsyyRFmT++miqSQs=; b=nYoKANQj9PxAnPI2z0Cbs4a5ch 5pZegsW8llmfpo/OYXgkC7AK5XETiGaEjvY5OiXWrmXkN95YbzS79gY1bki9XkVfvb/WlCdo1zQCM 4n+uYMyp5IzG3DeEh1YvMIx2DoyTcoC1abkcmnE9eKmJJjxQUxUvA+v3RIWWy3lWtgLcWnn2Q+SNn Vwekpcikip4scv/u+dZmYScRVJZ6bchj9TFa/XVKpUrCf19HnBKwRjz7FaDPHOwTEvQMqE4xjIi0D +40JAM92FNmyXlQf5qQZ+72+wCo4ORXD/a1WEGL01o9geBm3kvamageCPMB7xSYr8iRvHGsBE8oHW HCcilwhg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8SlX-0002pp-UZ; Wed, 19 Aug 2020 18:24:51 +0000 Received: from mx2.suse.de ([195.135.220.15]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8SlU-0002ob-T7; Wed, 19 Aug 2020 18:24:49 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CF93BAC85; Wed, 19 Aug 2020 18:25:12 +0000 (UTC) From: Nicolas Saenz Julienne To: linux-kernel@vger.kernel.org Subject: [RFC] arm64: mm: Do not use both DMA zones when 30-bit address space unavailable Date: Wed, 19 Aug 2020 20:24:33 +0200 Message-Id: <20200819182434.28196-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200819_142449_057205_2F1861BD X-CRM114-Status: GOOD ( 18.04 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [195.135.220.15 listed in wl.mailspike.net] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [195.135.220.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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: linux-arm-kernel@lists.infradead.org, f.fainelli@gmail.com, Catalin Marinas , linux-rpi-kernel@lists.infradead.org, Will Deacon , hch@lst.de, Nicolas Saenz Julienne Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org 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()); } static void __init zone_sizes_init(unsigned long min, unsigned long max) @@ -390,6 +397,20 @@ void __init arm64_memblock_init(void) if (IS_ENABLED(CONFIG_ZONE_DMA)) { zone_dma_bits = ARM64_ZONE_DMA_BITS; arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS); + + /* + * We don't want to split the 32 bit address space into two DMA + * zones when the target lower physical address range doesn't + * exist. For example, if memory starts at 0x80000000 it's + * pointless to create a ZONE_DMA distinct of ZONE_DMA32 as + * there's no way to access the 30-bit address space. If that's + * the case just expand ZONE_DMA to cover the whole 32-bit + * address space. + */ + if (!arm64_dma_phys_limit) { + zone_dma_bits = 32; + arm64_dma_phys_limit = max_zone_phys(32); + } } if (IS_ENABLED(CONFIG_ZONE_DMA32))