From patchwork Sun Nov 1 17:04:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 1391783 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=205.233.59.134; helo=merlin.infradead.org; envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=merlin.20170209 header.b=iKrsD5b7; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=Vz7hlCOf; dkim-atps=neutral Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CPMt63B9Qz9sRR for ; Mon, 2 Nov 2020 04:07:26 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=H7Tw2AldgB70smGOr5tlLYlVgjDJQVMLJ+JIi46Oi6I=; b=iKrsD5b7x3sTs4f/OXTPGzQBA SaR6+bnoOC133y83sPowsINpr9QKDhk8mOSGeFD59stLs1MuuhRNJMyFqh3i10xOQC7T0HeUjhSeu jyr1pERsUwgLxfdRNx0EH78m9FvVOsleV2tdhC+JDaFWT0MDK7EH9HTRMUzoabAIIqI86qO9LKYFp 0p/s9LWv71zcPQKiCRz/WNN19Cg0JibhnN639oml3G56cQ/v22h26GuGJYSD7qJ2PHjDNWXtNP6Ye wEqrGTf5A2MAbR7o/tAcoRRMcubd05ScTHBlSK6h2wLPyiLIN+0S1rfkT1KX6TLgemnp6D7Zq3Ty1 BYXfE+pXw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZGp9-0003I8-NT; Sun, 01 Nov 2020 17:07:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZGoF-0002rb-Ds; Sun, 01 Nov 2020 17:06:33 +0000 Received: from aquarius.haifa.ibm.com (nesher1.haifa.il.ibm.com [195.110.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 911202223F; Sun, 1 Nov 2020 17:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604250386; bh=fWxkbZL/5LT7MVmydGQvto+yiZVxeeiLovyNTt2+nMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vz7hlCOfEKvhdYdVx02tccXCR69Tgvys6SCSJ/AwADwwmLCxWzCZRFA3N4DSZ0TNf NMj2sjlY5sUvwwkqZVyNWvWsIKsoWRy4e5mWYOTcjMU9Z7iDHW/BBbA5ZKDtLBao9Y XcPPJPO0UL5x9C2pQixh7DUbitUwk4/sJ48l2D4E= From: Mike Rapoport To: Andrew Morton Subject: [PATCH v2 13/13] m68k: deprecate DISCONTIGMEM Date: Sun, 1 Nov 2020 19:04:54 +0200 Message-Id: <20201101170454.9567-14-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201101170454.9567-1-rppt@kernel.org> References: <20201101170454.9567-1-rppt@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201101_120627_656642_A0DE174C X-CRM114-Status: GOOD ( 22.19 ) X-Spam-Score: -5.2 (-----) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-5.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high trust [198.145.29.99 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-doc@vger.kernel.org, Catalin Marinas , linux-mm@kvack.org, Will Deacon , Greg Ungerer , Jonathan Corbet , Meelis Roos , Russell King , Mike Rapoport , Geert Uytterhoeven , Matt Turner , linux-snps-arc@lists.infradead.org, Alexey Dobriyan , linux-m68k@lists.linux-m68k.org, John Paul Adrian Glaubitz , linux-arm-kernel@lists.infradead.org, Michael Schmitz , Tony Luck , Vineet Gupta , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, Mike Rapoport Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Mike Rapoport DISCONTIGMEM was intended to provide more efficient support for systems with holes in their physical address space that FLATMEM did. Yet, it's overhead in terms of the memory consumption seems to overweight the savings on the unused memory map. For a ARAnyM system with 16 MBytes of FastRAM configured, the memory usage reported after page allocator initialization is Memory: 23828K/30720K available (3206K kernel code, 535K rwdata, 936K rodata, 768K init, 193K bss, 6892K reserved, 0K cma-reserved) and with DISCONTIGMEM disabled and with relatively large hole in the memory map it is: Memory: 23864K/30720K available (3197K kernel code, 516K rwdata, 936K rodata, 764K init, 179K bss, 6856K reserved, 0K cma-reserved) Moreover, since m68k already has custom pfn_valid() it is possible to define HAVE_ARCH_PFN_VALID to enable freeing of unused memory map. The minimal size of a hole that can be freed should not be less than MAX_ORDER_NR_PAGES so to achieve more substantial memory savings let m68k also define custom FORCE_MAX_ZONEORDER. With FORCE_MAX_ZONEORDER set to 9 memory usage becomes: Memory: 23880K/30720K available (3197K kernel code, 516K rwdata, 936K rodata, 764K init, 179K bss, 6840K reserved, 0K cma-reserved) Signed-off-by: Mike Rapoport --- arch/m68k/Kconfig.cpu | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index b8884af365ae..3e70fb7a8d83 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -20,6 +20,7 @@ choice config M68KCLASSIC bool "Classic M68K CPU family support" + select HAVE_ARCH_PFN_VALID config COLDFIRE bool "Coldfire CPU family support" @@ -377,11 +378,34 @@ config SINGLE_MEMORY_CHUNK help Ignore all but the first contiguous chunk of physical memory for VM purposes. This will save a few bytes kernel size and may speed up - some operations. Say N if not sure. + some operations. + When this option os set to N, you may want to lower "Maximum zone + order" to save memory that could be wasted for unused memory map. + Say N if not sure. config ARCH_DISCONTIGMEM_ENABLE + depends on BROKEN def_bool MMU && !SINGLE_MEMORY_CHUNK +config FORCE_MAX_ZONEORDER + int "Maximum zone order" if ADVANCED + depends on !SINGLE_MEMORY_CHUNK + default "11" + help + The kernel memory allocator divides physically contiguous memory + blocks into "zones", where each zone is a power of two number of + pages. This option selects the largest power of two that the kernel + keeps in the memory allocator. If you need to allocate very large + blocks of physically contiguous memory, then you may need to + increase this value. + + For systems that have holes in their physical address space this + value also defines the minimal size of the hole that allows + freeing unused memory map. + + This config option is actually maximum order plus one. For example, + a value of 11 means that the largest free memory block is 2^10 pages. + config 060_WRITETHROUGH bool "Use write-through caching for 68060 supervisor accesses" depends on ADVANCED && M68060