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=-11.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 9B817C433ED for ; Wed, 12 May 2021 08:32:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 61A53613BE for ; Wed, 12 May 2021 08:32:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230347AbhELIdX (ORCPT ); Wed, 12 May 2021 04:33:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:46212 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230114AbhELIdT (ORCPT ); Wed, 12 May 2021 04:33:19 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D7764611CE; Wed, 12 May 2021 08:32:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620808332; bh=kGPdN86b0Oq5p5oLcXPvPWzKj3IOJoZBJavrii5GWJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u1W34uKaeHf+2TfWF+yKruaaxLBevPABgP3RFO+ihcQRfaQWyQMLywPoJSxZ15e5A A+ZxEiWJ8lqLT/nh8LkxANdYWeNVcjbDVL52jt0gHwdHZOS4G1TFXASmfA/oDZ7agt PhRu+0VONPTYTzDkJwnftRawjodjzxYGidMGhEjt9yRU9H+jtjGoCTlod+OJnq+wca 11YeCdeNn8hWNAKihi0F3K865gkPlsUdThT2lOoK5R9zwC9O8I478n648PydiIRat/ cFltwBimFJJjk6SnaBYU9LdxCN9h3S8WYLeeyIQDqH6hCskx1ho2me2wvgtGocUr+L 0Kq+xkW4AbCkg== Date: Wed, 12 May 2021 11:32:02 +0300 From: Mike Rapoport To: Ard Biesheuvel Cc: Mike Rapoport , Andrew Morton , Anshuman Khandual , Catalin Marinas , David Hildenbrand , Marc Zyngier , Mark Rutland , Will Deacon , kvmarm , Linux ARM , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Message-ID: References: <20210511100550.28178-1-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 12, 2021 at 09:59:33AM +0200, Ard Biesheuvel wrote: > On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote: > > > > On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > > > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > > > > > From: Mike Rapoport > > > > > > > > Hi, > > > > > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > > > > pfn_valid_within() to 1. > > > > > > > > The idea is to mark NOMAP pages as reserved in the memory map and restore > > > > the intended semantics of pfn_valid() to designate availability of struct > > > > page for a pfn. > > > > > > > > With this the core mm will be able to cope with the fact that it cannot use > > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > > > > will be treated correctly even without the need for pfn_valid_within. > > > > > > > > The patches are boot tested on qemu-system-aarch64. > > > > > > > > > > Did you use EFI boot when testing this? The memory map is much more > > > fragmented in that case, so this would be a good data point. > > > > Right, something like this: > > > > Yes, although it is not always that bad. > > > [ 0.000000] Early memory node ranges > > [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000ffffbfff] > > [ 0.000000] node 0: [mem 0x00000000ffffc000-0x00000000ffffffff] > > This is allocated below 4 GB by the firmware, for reasons that are > only valid on x86 (where some of the early boot chain is IA32 only) > > > [ 0.000000] node 0: [mem 0x0000000100000000-0x00000004386fffff] > > [ 0.000000] node 0: [mem 0x0000000438700000-0x000000043899ffff] > > [ 0.000000] node 0: [mem 0x00000004389a0000-0x00000004389bffff] > > [ 0.000000] node 0: [mem 0x00000004389c0000-0x0000000438b5ffff] > > [ 0.000000] node 0: [mem 0x0000000438b60000-0x000000043be3ffff] > > [ 0.000000] node 0: [mem 0x000000043be40000-0x000000043becffff] > > [ 0.000000] node 0: [mem 0x000000043bed0000-0x000000043bedffff] > > [ 0.000000] node 0: [mem 0x000000043bee0000-0x000000043bffffff] > > [ 0.000000] node 0: [mem 0x000000043c000000-0x000000043fffffff] > > > > This is a pity really, because I don't see a fundamental reason for those > > tiny holes all over the place. > > > > There is a config option in the firmware build that allows these > regions to be preallocated using larger windows, which greatly reduces > the fragmentation. > > I know that EFI/ACPI mandates "IO style" memory access for those regions, > > but I fail to get why... > > > > Not sure what you mean by 'IO style memory access'. Well, my understanding is that the memory reserved by the firmware cannot be mapped in the linear map because it might require different caching modes (e.g like IO) and arm64 cannot tolerate aliased mappings with different caching. But what evades me is *why* these areas cannot be accessed as normal RAM. > > > > I beleive it would be best to route these via mmotm tree. > > > > > > > > v4: > > > > * rebase on v5.13-rc1 > > > > > > > > v3: Link: https://lore.kernel.org/lkml/20210422061902.21614-1-rppt@kernel.org > > > > * Fix minor issues found by Anshuman > > > > * Freshen up the declaration of pfn_valid() to make it consistent with > > > > pfn_is_map_memory() > > > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > > > > > v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-rppt@kernel.org > > > > * Add check for PFN overflow in pfn_is_map_memory() > > > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > > > > > v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt@kernel.org > > > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > > > * Use pfn_is_map_memory() name for the exported wrapper for > > > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > > > because of header dependency issues. > > > > > > > > rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt@kernel.org > > > > > > > > Mike Rapoport (4): > > > > include/linux/mmzone.h: add documentation for pfn_valid() > > > > memblock: update initialization of reserved pages > > > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > > > > > arch/arm64/Kconfig | 3 --- > > > > arch/arm64/include/asm/memory.h | 2 +- > > > > arch/arm64/include/asm/page.h | 3 ++- > > > > arch/arm64/kvm/mmu.c | 2 +- > > > > arch/arm64/mm/init.c | 14 +++++++++++++- > > > > arch/arm64/mm/ioremap.c | 4 ++-- > > > > arch/arm64/mm/mmu.c | 2 +- > > > > include/linux/memblock.h | 4 +++- > > > > include/linux/mmzone.h | 11 +++++++++++ > > > > mm/memblock.c | 28 ++++++++++++++++++++++++++-- > > > > 10 files changed, 60 insertions(+), 13 deletions(-) > > > > > > > > > > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > > > > -- > > > > 2.28.0 > > > > > > > > -- > > Sincerely yours, > > Mike. -- Sincerely yours, Mike. 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=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F2D5AC433B4 for ; Wed, 12 May 2021 08:32:18 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 47807613CF for ; Wed, 12 May 2021 08:32:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47807613CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B48B34B833; Wed, 12 May 2021 04:32:17 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7GLdYHqBB6X; Wed, 12 May 2021 04:32:16 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5F2454B3B1; Wed, 12 May 2021 04:32:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C6C864B37A for ; Wed, 12 May 2021 04:32:14 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0ImUZXDqsg1 for ; Wed, 12 May 2021 04:32:13 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 4ED084B365 for ; Wed, 12 May 2021 04:32:13 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id D7764611CE; Wed, 12 May 2021 08:32:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620808332; bh=kGPdN86b0Oq5p5oLcXPvPWzKj3IOJoZBJavrii5GWJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u1W34uKaeHf+2TfWF+yKruaaxLBevPABgP3RFO+ihcQRfaQWyQMLywPoJSxZ15e5A A+ZxEiWJ8lqLT/nh8LkxANdYWeNVcjbDVL52jt0gHwdHZOS4G1TFXASmfA/oDZ7agt PhRu+0VONPTYTzDkJwnftRawjodjzxYGidMGhEjt9yRU9H+jtjGoCTlod+OJnq+wca 11YeCdeNn8hWNAKihi0F3K865gkPlsUdThT2lOoK5R9zwC9O8I478n648PydiIRat/ cFltwBimFJJjk6SnaBYU9LdxCN9h3S8WYLeeyIQDqH6hCskx1ho2me2wvgtGocUr+L 0Kq+xkW4AbCkg== Date: Wed, 12 May 2021 11:32:02 +0300 From: Mike Rapoport To: Ard Biesheuvel Subject: Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Message-ID: References: <20210511100550.28178-1-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Anshuman Khandual , Catalin Marinas , David Hildenbrand , Linux Kernel Mailing List , Mike Rapoport , Linux Memory Management List , Marc Zyngier , Andrew Morton , Will Deacon , kvmarm , Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, May 12, 2021 at 09:59:33AM +0200, Ard Biesheuvel wrote: > On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote: > > > > On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > > > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > > > > > From: Mike Rapoport > > > > > > > > Hi, > > > > > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > > > > pfn_valid_within() to 1. > > > > > > > > The idea is to mark NOMAP pages as reserved in the memory map and restore > > > > the intended semantics of pfn_valid() to designate availability of struct > > > > page for a pfn. > > > > > > > > With this the core mm will be able to cope with the fact that it cannot use > > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > > > > will be treated correctly even without the need for pfn_valid_within. > > > > > > > > The patches are boot tested on qemu-system-aarch64. > > > > > > > > > > Did you use EFI boot when testing this? The memory map is much more > > > fragmented in that case, so this would be a good data point. > > > > Right, something like this: > > > > Yes, although it is not always that bad. > > > [ 0.000000] Early memory node ranges > > [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000ffffbfff] > > [ 0.000000] node 0: [mem 0x00000000ffffc000-0x00000000ffffffff] > > This is allocated below 4 GB by the firmware, for reasons that are > only valid on x86 (where some of the early boot chain is IA32 only) > > > [ 0.000000] node 0: [mem 0x0000000100000000-0x00000004386fffff] > > [ 0.000000] node 0: [mem 0x0000000438700000-0x000000043899ffff] > > [ 0.000000] node 0: [mem 0x00000004389a0000-0x00000004389bffff] > > [ 0.000000] node 0: [mem 0x00000004389c0000-0x0000000438b5ffff] > > [ 0.000000] node 0: [mem 0x0000000438b60000-0x000000043be3ffff] > > [ 0.000000] node 0: [mem 0x000000043be40000-0x000000043becffff] > > [ 0.000000] node 0: [mem 0x000000043bed0000-0x000000043bedffff] > > [ 0.000000] node 0: [mem 0x000000043bee0000-0x000000043bffffff] > > [ 0.000000] node 0: [mem 0x000000043c000000-0x000000043fffffff] > > > > This is a pity really, because I don't see a fundamental reason for those > > tiny holes all over the place. > > > > There is a config option in the firmware build that allows these > regions to be preallocated using larger windows, which greatly reduces > the fragmentation. > > I know that EFI/ACPI mandates "IO style" memory access for those regions, > > but I fail to get why... > > > > Not sure what you mean by 'IO style memory access'. Well, my understanding is that the memory reserved by the firmware cannot be mapped in the linear map because it might require different caching modes (e.g like IO) and arm64 cannot tolerate aliased mappings with different caching. But what evades me is *why* these areas cannot be accessed as normal RAM. > > > > I beleive it would be best to route these via mmotm tree. > > > > > > > > v4: > > > > * rebase on v5.13-rc1 > > > > > > > > v3: Link: https://lore.kernel.org/lkml/20210422061902.21614-1-rppt@kernel.org > > > > * Fix minor issues found by Anshuman > > > > * Freshen up the declaration of pfn_valid() to make it consistent with > > > > pfn_is_map_memory() > > > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > > > > > v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-rppt@kernel.org > > > > * Add check for PFN overflow in pfn_is_map_memory() > > > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > > > > > v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt@kernel.org > > > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > > > * Use pfn_is_map_memory() name for the exported wrapper for > > > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > > > because of header dependency issues. > > > > > > > > rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt@kernel.org > > > > > > > > Mike Rapoport (4): > > > > include/linux/mmzone.h: add documentation for pfn_valid() > > > > memblock: update initialization of reserved pages > > > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > > > > > arch/arm64/Kconfig | 3 --- > > > > arch/arm64/include/asm/memory.h | 2 +- > > > > arch/arm64/include/asm/page.h | 3 ++- > > > > arch/arm64/kvm/mmu.c | 2 +- > > > > arch/arm64/mm/init.c | 14 +++++++++++++- > > > > arch/arm64/mm/ioremap.c | 4 ++-- > > > > arch/arm64/mm/mmu.c | 2 +- > > > > include/linux/memblock.h | 4 +++- > > > > include/linux/mmzone.h | 11 +++++++++++ > > > > mm/memblock.c | 28 ++++++++++++++++++++++++++-- > > > > 10 files changed, 60 insertions(+), 13 deletions(-) > > > > > > > > > > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > > > > -- > > > > 2.28.0 > > > > > > > > -- > > Sincerely yours, > > Mike. -- Sincerely yours, Mike. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 89D3DC433ED for ; Wed, 12 May 2021 08:34:46 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 DAF51613CA for ; Wed, 12 May 2021 08:34:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAF51613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc: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=GCEP9ctgGV6OGdUHduCEG9a5FXIu2NbuhmFUUumKaQk=; b=URrjPfOyQgf+QC1LDI43HjzBV SAY8mdpYYfE237+T/fxtuzmNCfsg0VC+Ai2XnUzxik4jISHyvjmioZEvyWrANqxkFNGTcqraOnblO SOcvoB2lW6ciziD5VHwIr1rtsEG2/u25POm7lli6BVMzSyGSU3fMLJCExkBeMgJmmNG9k6j25MMgx gAAakDpBgB8izaFkTAX4qlMqAMCg1Q8hxmTesfddWJkiJJvXCqfSR9D8sT2jk5s1jns1O8YafFM8q 0J5PyZJS6CUnfrIpmQ8dfB9+9vT8jrFJWckhPv5MvUa22/XXSJFb7yfmhLlp8Q9BXXyt7JPfagpId YIsGJ5Jig==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lgkHz-002KII-09; Wed, 12 May 2021 08:32:19 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lgkHv-002KI7-OK for linux-arm-kernel@desiato.infradead.org; Wed, 12 May 2021 08:32:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UYnorWDUMpXFylR7NGJnpUgwzypuJ2DHrUxOs3vjEsY=; b=I4/Ib3Yja7B4Ld2ToqHkj13BnX L+joCsHQ8vxglSq4nABndt7QlpQR4LdnViv8YVQnSiEPzczwb+mDxLecFT+R8UADkDtIgofN8U/kd MQFXGlRg2joegUJsURPjFRIXFY9PV4CqFe9J31UBJ1hsfXX+ogRNGiMv+eQFunwQm12pWh4THMyg5 ePN5zYLpZ1MajWuYlynTEN+CeHo+5FLzcvbozA6Vy032VEsm+gpZETIZvydLDO7e4PB83G8SV6q6Y awNFiHM/bukQ7VdxglP9zws6DrtNzm3OLFtaCtEoWlLUKcxLqt8Db7G7XqqnCTwNmgem3Luochwi8 e055LPeg==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lgkHs-00ADDE-M0 for linux-arm-kernel@lists.infradead.org; Wed, 12 May 2021 08:32:14 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id D7764611CE; Wed, 12 May 2021 08:32:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620808332; bh=kGPdN86b0Oq5p5oLcXPvPWzKj3IOJoZBJavrii5GWJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u1W34uKaeHf+2TfWF+yKruaaxLBevPABgP3RFO+ihcQRfaQWyQMLywPoJSxZ15e5A A+ZxEiWJ8lqLT/nh8LkxANdYWeNVcjbDVL52jt0gHwdHZOS4G1TFXASmfA/oDZ7agt PhRu+0VONPTYTzDkJwnftRawjodjzxYGidMGhEjt9yRU9H+jtjGoCTlod+OJnq+wca 11YeCdeNn8hWNAKihi0F3K865gkPlsUdThT2lOoK5R9zwC9O8I478n648PydiIRat/ cFltwBimFJJjk6SnaBYU9LdxCN9h3S8WYLeeyIQDqH6hCskx1ho2me2wvgtGocUr+L 0Kq+xkW4AbCkg== Date: Wed, 12 May 2021 11:32:02 +0300 From: Mike Rapoport To: Ard Biesheuvel Cc: Mike Rapoport , Andrew Morton , Anshuman Khandual , Catalin Marinas , David Hildenbrand , Marc Zyngier , Mark Rutland , Will Deacon , kvmarm , Linux ARM , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Message-ID: References: <20210511100550.28178-1-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210512_013212_820660_C8B68C86 X-CRM114-Status: GOOD ( 39.65 ) 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: , 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 On Wed, May 12, 2021 at 09:59:33AM +0200, Ard Biesheuvel wrote: > On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote: > > > > On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > > > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > > > > > From: Mike Rapoport > > > > > > > > Hi, > > > > > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > > > > pfn_valid_within() to 1. > > > > > > > > The idea is to mark NOMAP pages as reserved in the memory map and restore > > > > the intended semantics of pfn_valid() to designate availability of struct > > > > page for a pfn. > > > > > > > > With this the core mm will be able to cope with the fact that it cannot use > > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > > > > will be treated correctly even without the need for pfn_valid_within. > > > > > > > > The patches are boot tested on qemu-system-aarch64. > > > > > > > > > > Did you use EFI boot when testing this? The memory map is much more > > > fragmented in that case, so this would be a good data point. > > > > Right, something like this: > > > > Yes, although it is not always that bad. > > > [ 0.000000] Early memory node ranges > > [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000ffffbfff] > > [ 0.000000] node 0: [mem 0x00000000ffffc000-0x00000000ffffffff] > > This is allocated below 4 GB by the firmware, for reasons that are > only valid on x86 (where some of the early boot chain is IA32 only) > > > [ 0.000000] node 0: [mem 0x0000000100000000-0x00000004386fffff] > > [ 0.000000] node 0: [mem 0x0000000438700000-0x000000043899ffff] > > [ 0.000000] node 0: [mem 0x00000004389a0000-0x00000004389bffff] > > [ 0.000000] node 0: [mem 0x00000004389c0000-0x0000000438b5ffff] > > [ 0.000000] node 0: [mem 0x0000000438b60000-0x000000043be3ffff] > > [ 0.000000] node 0: [mem 0x000000043be40000-0x000000043becffff] > > [ 0.000000] node 0: [mem 0x000000043bed0000-0x000000043bedffff] > > [ 0.000000] node 0: [mem 0x000000043bee0000-0x000000043bffffff] > > [ 0.000000] node 0: [mem 0x000000043c000000-0x000000043fffffff] > > > > This is a pity really, because I don't see a fundamental reason for those > > tiny holes all over the place. > > > > There is a config option in the firmware build that allows these > regions to be preallocated using larger windows, which greatly reduces > the fragmentation. > > I know that EFI/ACPI mandates "IO style" memory access for those regions, > > but I fail to get why... > > > > Not sure what you mean by 'IO style memory access'. Well, my understanding is that the memory reserved by the firmware cannot be mapped in the linear map because it might require different caching modes (e.g like IO) and arm64 cannot tolerate aliased mappings with different caching. But what evades me is *why* these areas cannot be accessed as normal RAM. > > > > I beleive it would be best to route these via mmotm tree. > > > > > > > > v4: > > > > * rebase on v5.13-rc1 > > > > > > > > v3: Link: https://lore.kernel.org/lkml/20210422061902.21614-1-rppt@kernel.org > > > > * Fix minor issues found by Anshuman > > > > * Freshen up the declaration of pfn_valid() to make it consistent with > > > > pfn_is_map_memory() > > > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > > > > > v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-rppt@kernel.org > > > > * Add check for PFN overflow in pfn_is_map_memory() > > > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > > > > > v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt@kernel.org > > > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > > > * Use pfn_is_map_memory() name for the exported wrapper for > > > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > > > because of header dependency issues. > > > > > > > > rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt@kernel.org > > > > > > > > Mike Rapoport (4): > > > > include/linux/mmzone.h: add documentation for pfn_valid() > > > > memblock: update initialization of reserved pages > > > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > > > > > arch/arm64/Kconfig | 3 --- > > > > arch/arm64/include/asm/memory.h | 2 +- > > > > arch/arm64/include/asm/page.h | 3 ++- > > > > arch/arm64/kvm/mmu.c | 2 +- > > > > arch/arm64/mm/init.c | 14 +++++++++++++- > > > > arch/arm64/mm/ioremap.c | 4 ++-- > > > > arch/arm64/mm/mmu.c | 2 +- > > > > include/linux/memblock.h | 4 +++- > > > > include/linux/mmzone.h | 11 +++++++++++ > > > > mm/memblock.c | 28 ++++++++++++++++++++++++++-- > > > > 10 files changed, 60 insertions(+), 13 deletions(-) > > > > > > > > > > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > > > > -- > > > > 2.28.0 > > > > > > > > -- > > Sincerely yours, > > Mike. -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel