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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 B64B4C433DB for ; Thu, 11 Mar 2021 08:16:13 +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 0E62F64EAE for ; Thu, 11 Mar 2021 08:16:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E62F64EAE 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=c96AN3lOoAW9lyu0eGxUO3lgNk2sXDIUOOuKdfS9c64=; b=KAh/CSoy4Hqn3fa+90GX86TiG MMvSGn1qy29mKbXz/X4h/Cm020ppo+5ACQs/Nx3jYfZ4u+VLN4q09FoRE1KqIp80EKWCuv7iBpn0z 2HGI8LHl0yXWEcu1i9cXw5UI6NTsZJWtBbfhKO5cS0HPkmthZ/M7/1bWIQk5wKXlBTQ2Cdq0CghDZ 1kvQy1fvwR5a+VMsopFJackVP3+ZSq13TBm69Newmyyj3kBbk4SwlHUZasna1xTlE7ez0TMnzOmNs BY/tF3O5hyUA6K+OrTtov78LX3uvffhZOyj6VdjJHL5yr8czpCI3nHd3uVPaC9ATpDe5m03y1cG/v XxFsWUing==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lKGT3-008f2U-0V; Thu, 11 Mar 2021 08:14:49 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lKGSy-008f1s-Jc for linux-arm-kernel@lists.infradead.org; Thu, 11 Mar 2021 08:14:46 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id DE46E64EC6; Thu, 11 Mar 2021 08:14:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615450482; bh=a3b4TtFfggtZVB8E1vmzTQlVeIFZQfTnkixKH/vWHHc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lyUDDmYV+k+pnkiQGiBHE/zGBr5bgPSafkHqV2CsbXJOoYcYfFmutNQku0O5VIeiC h2TvwatDhw8pNHXzfArY/lDLFykTQMe8utgh/Ar+kuMYDyTgaQIOTvlULzE4Hd0SNW T7YJrepd0AgeRdVGq6rimfcckSC0K+tdBbOhjPmMCo+8OSzwFMIxyps7FkTds48HD4 5ZzBs0dUce2ZjFZg/g+E+/HxtFh9AS4Ujc+Lcy8E0HtMvJ2auIkklqEVIjLEaXBNIt 6IsLv/+ixlCmcFj5xCZ/DvDBEa25xnxSxE8R5r5+4OLz+IHyI5XvKedCfpGhDfZhK7 s7qm5GpzJDsig== Date: Thu, 11 Mar 2021 10:14:35 +0200 From: Mike Rapoport To: Anshuman Khandual Cc: linux-mm@kvack.org, Russell King , Catalin Marinas , Will Deacon , Andrew Morton , David Hildenbrand , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] mm: Enable generic pfn_valid() to handle early sections with memmap holes Message-ID: References: <1615174073-10520-1-git-send-email-anshuman.khandual@arm.com> <003d8a4b-9687-3e9a-c27b-908db280b44c@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <003d8a4b-9687-3e9a-c27b-908db280b44c@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210311_081445_049743_45F81233 X-CRM114-Status: GOOD ( 32.41 ) 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 Thu, Mar 11, 2021 at 01:22:53PM +0530, Anshuman Khandual wrote: > > On 3/8/21 2:25 PM, Mike Rapoport wrote: > > Hi Anshuman, > > > > On Mon, Mar 08, 2021 at 08:57:53AM +0530, Anshuman Khandual wrote: > >> Platforms like arm and arm64 have redefined pfn_valid() because their early > >> memory sections might have contained memmap holes caused by memblock areas > >> tagged with MEMBLOCK_NOMAP, which should be skipped while validating a pfn > >> for struct page backing. This scenario could be captured with a new option > >> CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES and then generic pfn_valid() can be > >> improved to accommodate such platforms. This reduces overall code footprint > >> and also improves maintainability. > > > > I wonder whether arm64 would still need to free parts of its memmap after > > free_unused_memmap() is applicable when CONFIG_SPARSEMEM_VMEMMAP is not enabled. > I am not sure whether there still might be some platforms or boards which would > benefit from this. Hence lets just keep this unchanged for now. For builds with VMEMMAP off free_unused_memmap() would still provide some memory savings. But the question is whether these savings are really important for somebody? When the section size was 512M no doubt smaller systems would waste a lot of memory for empty memory map. But with the section size of 128M and the general increase in memory sizes even on smaller devices we might be not actually saving anything. OTOH, we need to keep arm64::pfn_valid() up to date with memory hot(un)plug, ZONE_DEVICE etc. Maybe as a compromise we can start with making free_unused_memmap() and arm64::pfn_valid() only available in "legacy" mode that does not support memory hotplug, pmem and so on? > > the section size was reduced. Maybe the pain of arm64::pfn_valid() is not > > worth the memory savings anymore? > > arm64 pfn_valid() special case was primarily because of MEMBLOCK_NOMAP tagged > memory areas, which are reserved by the firmware. I'm confused now. AFAIU, pfn_valid() means that there is a struct page for that pfn and nothing else. Why is that related to MEMBLOCK_NOMAP? > > > >> Commit 4f5b0c178996 ("arm, arm64: move free_unused_memmap() to generic mm") > >> had used CONFIG_HAVE_ARCH_PFN_VALID to gate free_unused_memmap(), which in > >> turn had expanded its scope to new platforms like arc and m68k. Rather lets > >> restrict back the scope for free_unused_memmap() to arm and arm64 platforms > >> using this new config option i.e CONFIG_HAVE_EARLY_SECTION_MEMMAP. > > > > The whole point of 4f5b0c178996 was to let arc and m68k to free unused > > memory map with FLATMEM so they won't need DISCONTIGMEM or SPARSEMEM. So > > whatever implementation there will be for arm/arm64, please keep arc and > > m68k functionally intact. > > Okay. Will protect free_unused_memmap() on HAVE_EARLY_SECTION_MEMMAP_HOLES > config as well. > > diff --git a/mm/memblock.c b/mm/memblock.c > index d9fa2e62ab7a..11b624e94127 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1927,8 +1927,11 @@ static void __init free_unused_memmap(void) > unsigned long start, end, prev_end = 0; > int i; > > - if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) || > - IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP)) > + if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP)) > + return; > + > + if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) && > + !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID)) > return; -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel