Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp123606pxf; Wed, 7 Apr 2021 22:13:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTiDs4Wmbbr+8sEt6FYDLUEu9vRd7bEtrczL5fhs5qhbKDtAoMksjjrEHQ4josBNOpudU7 X-Received: by 2002:a17:907:921:: with SMTP id au1mr7677285ejc.386.1617858791721; Wed, 07 Apr 2021 22:13:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617858791; cv=none; d=google.com; s=arc-20160816; b=vxQtNPQ3oCgnsTg7ihy/X+VSaYJDIr99FtZDtRmOrOYGuPX0AkPieetpgb4uH0JW0M MJWdO2Bo53k9V+9u3Wm4WVLJOJdywKLOEUWD00h+MqPWI54GMZN4SZ99GjJK9zzXQSoH dF865VOCShf8SMmyyl33UtGL1zDEzDmnf0vXyh7uQuaPLeMSBSf/kAf43am75E7PpR0c Q5b0/UxdBtTceA5lweuaHJjyE70T95TxrrqgMw6OoGj0htC24uJV11vAEotnrPh+Dwxm vnaP31yirZ+KuOhJ4Imd3kwo+NQYRguE21TKgv1wjJEg8ceXPxAH5dEx6eb9tGoW8QRM 8HTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=DmxdUGfLhHeVL6cq4Q3jQq90rNV+QC0xC9ODM3x8ePY=; b=uV2tH+td9Nb2Htyof4tJOdHc2weXw1RQUnghEQZbybW6f1QgtAcjgyJqLD8C9z5h5G udNPFHges2BjBibAkkhqMwbOuCEK/8kOqr/rZujdubBAmfRbBWSmP/je6bNVFpV2dmir oaZjPIpJ+3fUmFhjbzronEvkWIZWMm6VLn2KiOHOniHk9foQuVnwo/R7xCgBj9U9avcO QOeiT+gWCanJP2y7nmXl7TdKlEvSgc5ct2K4S3VIkl89krX+lDXUGW90Aex+MASE+peM HiPUGbms0G3h4WyPRPihDZUpiijKTC7zh0ux5TvsvqDosBziLS6l5qXJWlPs9TVocdZl SMDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n3si20549458ejz.565.2021.04.07.22.12.48; Wed, 07 Apr 2021 22:13:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229559AbhDHFMK (ORCPT + 99 others); Thu, 8 Apr 2021 01:12:10 -0400 Received: from foss.arm.com ([217.140.110.172]:39364 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbhDHFMJ (ORCPT ); Thu, 8 Apr 2021 01:12:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C3EE81424; Wed, 7 Apr 2021 22:11:58 -0700 (PDT) Received: from [10.163.67.84] (unknown [10.163.67.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29B6E3F73D; Wed, 7 Apr 2021 22:11:54 -0700 (PDT) Subject: Re: [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify pfn_valid() To: Mike Rapoport , linux-arm-kernel@lists.infradead.org Cc: 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 References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-4-rppt@kernel.org> From: Anshuman Khandual Message-ID: <7bc09505-72f1-e297-40a9-639b3e9b1c61@arm.com> Date: Thu, 8 Apr 2021 10:42:43 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210407172607.8812-4-rppt@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/7/21 10:56 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. But what about the memory map that are freed during boot (mentioned above). Would not they still cause CONFIG_HOLES_IN_ZONE to be applicable and hence pfn_valid_within() ? > > pfn_valid() can be slightly simplified by replacing > memblock_is_map_memory() with memblock_is_memory(). Just to understand this better, pfn_valid() will now return true for all MEMBLOCK_NOMAP based memory but that is okay as core MM would still ignore them as unusable memory for being PageReserved(). > > 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 > - > source "kernel/Kconfig.hz" > > config ARCH_SPARSEMEM_ENABLE > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 258b1905ed4a..bb6dd406b1f0 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); > } > EXPORT_SYMBOL(pfn_valid); > >