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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 08285C433B4 for ; Tue, 18 May 2021 10:55: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 C478161209 for ; Tue, 18 May 2021 10:55:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C478161209 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=hOZocD7hsBQ3iyGk2E5YtGn0LP8/vo+5xiZklt2YxDI=; b=Q1WqUjO1U6bgBmynQLntPIQ38 +3rSVflaruIROtG2iTCxtZhl0Gpu34wEU77E8kOzvfZ7xyYjwF+TGQP4VmcgLNulI1ebUaAe0Ri+w /lvD+ZOjWxIys4toPvmQAXoxtHRqc8aoA57/6myl7+HBSLSO5L/WV4YpU4vePQt6aR6Sfn86pjwGz SEoQX+/Cs9jUbZ05SOSGoT1M1R6Gch9n71frzjc2wTrg92+VCJKoKooYgdta//XZwJ8H6gkZ5OJby vosvmMNndzmkljQ2XhoEo1XPjzh5EvZfpPT1+1QaGF5mEd9LH2/KP7vQzI732vZ9GpI94FGyndID3 jRu/wkR/w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lixMN-000SMv-QP; Tue, 18 May 2021 10:53:59 +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 1lixML-000SMG-0m for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 10:53:57 +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=DUgK7v3cKuqMkOX7DYw9alefFyvWuhEZxm9zFBItpwc=; b=PbkNazz8/P53jXSoUeJ+S/QC7t /NrDCQOOfAcjcUev/wDHoV1sgHMDYe2P0CnxkbcKNV8wkfCIYeYUaNMu5UrdIx9ZUVByYIb4RI5N4 10MX5tkrFb5NMgWEAz02R5ch81P4+e3sJ8HLvRtuwjO+Lf0E7dxH9AOdcZva0bEOnjfyjzOQlEO7z 3MwxSOZVQatrKAJKuTcMo9glhI5RHYxviYD5+SHpvAO3X5iUzfihW1xNWCCKy43qYM+JVHyMvMNY5 uUJ0AciQU1yyJYy9NSNf7S27XtpBEH4PcnnKTYR8WZanPAL3YbKaDLhwkzZW0XMKo0nfe5YFlgNDV Qh5SFUYQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lixMI-00Ea9h-5n for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 10:53:55 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 530AE61209; Tue, 18 May 2021 10:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621335233; bh=1albl1iFT7lO5QgNDVJ5jG4lfAFdGkvbnRzuLTqjPyM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EXYY4DqSW4QsbgaQL6QXi6ZdeHaDW0T9FE0beaOSIKCYCn9kq/YT0pBgfFKzJadpq mg5IKthMepa5IUsNYEkt7XZupKPjSMoT0FDUPkt/n06x5N3wRKbnBLI5QuiHOGA38I v1sopQyLLuJ1Jp+PeDm/2Aqv9H1VE4+nLlqnIzu3lZf0JKdAHh7vB87BSwcu0W2QF1 Mm0tUX9k4jU+m5LuGtr3Zz+n2x7YGZwmWnytR53m/Pu+EUpYAZJs3J3k34MB3DHx9H UJBMJJgMhHbV2RIBzRl/BPZAL+O9wT3vpsNgHQDWU+EwzBjPXmV7Ije2PISjlP3VXM sSXb3k9WsydOg== Date: Tue, 18 May 2021 13:53:46 +0300 From: Mike Rapoport To: "Russell King (Oracle)" Cc: linux-arm-kernel@lists.infradead.org, Andrew Morton , Kefeng Wang , Mike Rapoport , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 3/3] arm: extend pfn_valid to take into accound freed memory map alignment Message-ID: References: <20210518090613.21519-1-rppt@kernel.org> <20210518090613.21519-4-rppt@kernel.org> <20210518094427.GR12395@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210518094427.GR12395@shell.armlinux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_035354_260591_62423796 X-CRM114-Status: GOOD ( 16.71 ) 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 Tue, May 18, 2021 at 10:44:27AM +0100, Russell King (Oracle) wrote: > On Tue, May 18, 2021 at 12:06:13PM +0300, Mike Rapoport wrote: > > From: Mike Rapoport > > > > When unused memory map is freed the preserved part of the memory map is > > extended to match pageblock boundaries because lots of core mm > > functionality relies on homogeneity of the memory map within pageblock > > boundaries. > > > > Since pfn_valid() is used to check whether there is a valid memory map > > entry for a PFN, make it return true also for PFNs that have memory map > > entries even if there is no actual memory populated there. > > I thought pfn_valid() was a particularly hot path... do we really want > to be doing multiple lookups here? Is there no better solution? It is hot, but for more, hmm, straightforward memory layouts it'll take if (memblock_is_map_memory(addr)) return 1; branch, I think. Most of mm operations are on pages that are fed into buddy allocator, and if there are no holes with weird alignment pfn_valid() will return 1 right away. Now thinking about it, with the patch that marks NOMAP areas reserved in the memory map [1], we could also use memblock_overlaps_region(&memblock.memory, ALIGN_DOWN(addr, pageblock_size), ALIGN(addr + 1, pageblock_size)) to have only one lookup. Completely another approach would be to simply stop freeing memory map with SPARSEMEM. For systems like the one Kefen is using, it would waste less than 2M out of 1.5G. It is worse of course for old systems with small memories. The worst case being mach-ep93xx with sections size of 256M and I presume 16M per section would be normal for such machines. [1] https://lore.kernel.org/lkml/20210511100550.28178-3-rppt@kernel.org -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel