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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5C686C43460 for ; Wed, 21 Apr 2021 12:26:12 +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 B71406144D for ; Wed, 21 Apr 2021 12:26:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B71406144D 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=1OJbDzLt2zLqaTnyD3rAE0IRhSSCg4ly7vgE/5QiPUI=; b=bxE5MhoVVrjyxmwphJ8xst7N5 plwPumUsDlOMS8JDPNhDKeoi0TnpDpLoVIvidqQpBNMEV3HJSMazOrP7BgvEcI5OVHpm9ga6TGivs eeXYAvNISim3wv1HqnWLcjGT/AvYOUvddz0lwJRMKQVkXVBkWA/Z5ROJ3rwXcw4Pt8tdNDcT5vRnA pK8AgjvZpUE9mfZi6Wql1zWD5EWljOaMbEObubhNz2Z6yMqbjh0jHsw8ZH4u0eYMP2h7b/D/e98m/ FOAbHMeoeYLhejIorKy/V2Mjg68UaMOOU6bd/Up3xMLsMcUZuQBupIxH6IL30j3BreF2yaUYf0ZUT nRdWbYGQA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZBtw-00ENUp-Kd; Wed, 21 Apr 2021 12:24:17 +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 1lZBtt-00ENUc-BQ for linux-arm-kernel@desiato.infradead.org; Wed, 21 Apr 2021 12:24:13 +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=t0N41gybRraHLNw0BwubGNGkHh1iEVfzABoPltyeuqg=; b=qmGSypwuXXx5NRYhudy61TcCnu dNWSRPmdypbrgEBkUPnWsyIYH4vneKAY0I7cXXH2rmwPl9fytiIus8ZGINRd0oKCqEBrb3HlUtOvk xw8Qvbas8yw+ecX/HHJThST9qc+L6w/xpYFg+uJzmMwOYGb/nmw/B0Ql0fNg2JeCic5CF88w9Urgq aYxoz+KJQ674hHQpoTalA+4kvom/977YpCsoN4dNSHV4IjAw05IcbZXdWkBeM3kvzmEhDCZwS+2/c 0N69WsRIXbZB+s00sTQ1kWqthAqA6SY3zJOntbzYIaBRjruPg/mcP8RvYdpQXkW7WXehK2RRfj2w+ YbIf94rg==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZBtq-00Crj5-Hf for linux-arm-kernel@lists.infradead.org; Wed, 21 Apr 2021 12:24:11 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id A066F61413; Wed, 21 Apr 2021 12:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619007849; bh=yh6as9NWrw83rUxIIucPP9c/DuWOHZ6hcJhSm2Fn9Ok=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f860jUcnW8H/ZBnBJQDe/Z6caOzDRAGPY71Yij6AZzc/ZM/zzjOtrh/+5CE5GsVGq pcCQEa6epu4I83oTKrt74ImgnXKtd9KyRgmfsqGZlr8Bt59P8mseStzqzZTTH+JDEv cbASQV89YWSTPadoCjBpoVNYoVZbCHv0LUMT5QYw4AJn8DnrowVzXcs76egO3nAEsD SYrstjJsa5Io7QYCgk/PjQ3RSqScp6IHEZpfmMUBy4G8/OpnJJOhVxKPX5lRTdWVDV mwcCMR9hEV/F0b2ygmBKDOm4YPpGvmDG+pNyGhOOBdY1GklZRKtgBMeykKpPRCVOqv /5gpsy2wh2JtQ== Date: Wed, 21 Apr 2021 15:24:01 +0300 From: Mike Rapoport To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Andrew Morton , Ard Biesheuvel , Catalin Marinas , David Hildenbrand , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Message-ID: References: <20210421065108.1987-1-rppt@kernel.org> <20210421065108.1987-5-rppt@kernel.org> <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210421_052410_692429_E7F5808B X-CRM114-Status: GOOD ( 34.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: , 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, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote: > > On 4/21/21 12:21 PM, Mike Rapoport wrote: > > From: Mike Rapoport > > > > The arm64's version of pfn_valid() differs from the generic because of two > > reasons: > > > > * Parts of the memory map are freed during boot. This makes it necessary to > > verify that there is actual physical memory that corresponds to a pfn > > which is done by querying memblock. > > > > * There are NOMAP memory regions. These regions are not mapped in the > > linear map and until the previous commit the struct pages representing > > these areas had default values. > > > > As the consequence of absence of the special treatment of NOMAP regions in > > the memory map it was necessary to use memblock_is_map_memory() in > > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that > > generic mm functionality would not treat a NOMAP page as a normal page. > > > > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and > > the rest of core mm will treat them as unusable memory and thus > > pfn_valid_within() is no longer required at all and can be disabled by > > removing CONFIG_HOLES_IN_ZONE on arm64. > > This makes sense. > > > > > pfn_valid() can be slightly simplified by replacing > > memblock_is_map_memory() with memblock_is_memory(). > > > > Signed-off-by: Mike Rapoport > > --- > > arch/arm64/Kconfig | 3 --- > > arch/arm64/mm/init.c | 4 ++-- > > 2 files changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > index e4e1b6550115..58e439046d05 100644 > > --- a/arch/arm64/Kconfig > > +++ b/arch/arm64/Kconfig > > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK > > def_bool y > > depends on NUMA > > > > -config HOLES_IN_ZONE > > - def_bool y > > - > > Right. > > > source "kernel/Kconfig.hz" > > > > config ARCH_SPARSEMEM_ENABLE > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index dc03bdc12c0f..eb3f56fb8c7c 100644 > > --- a/arch/arm64/mm/init.c > > +++ b/arch/arm64/mm/init.c > > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn) > > > > /* > > * ZONE_DEVICE memory does not have the memblock entries. > > - * memblock_is_map_memory() check for ZONE_DEVICE based > > + * memblock_is_memory() check for ZONE_DEVICE based > > * addresses will always fail. Even the normal hotplugged > > * memory will never have MEMBLOCK_NOMAP flag set in their > > * memblock entries. Skip memblock search for all non early > > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn) > > return pfn_section_valid(ms, pfn); > > } > > #endif > > - return memblock_is_map_memory(addr); > > + return memblock_is_memory(addr); > > Wondering if MEMBLOCK_NOMAP is now being treated similarly to other > memory pfns for page table walking purpose but with PageReserved(), > why memblock_is_memory() is still required ? At this point, should > not we just return valid for early_section() memory. As pfn_valid() > now just implies that pfn has a struct page backing which has been > already verified with valid_section() etc. memblock_is_memory() is required because arm64 frees unused parts of the memory map. So, for instance, if we have 64M out of 128M populated in a section the section based calculation would return 1 for a pfn in the second half of the section, but there would be no memory map there. > > } > > EXPORT_SYMBOL(pfn_valid); > > > > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel