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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8CA5C25B4F for ; Fri, 10 May 2024 09:03:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 711256B0098; Fri, 10 May 2024 05:03:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C1886B0099; Fri, 10 May 2024 05:03:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5891E6B009A; Fri, 10 May 2024 05:03:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3A84F6B0098 for ; Fri, 10 May 2024 05:03:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DC4731616FE for ; Fri, 10 May 2024 09:03:19 +0000 (UTC) X-FDA: 82101897318.19.150CCC1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf13.hostedemail.com (Postfix) with ESMTP id B46ED2000B for ; Fri, 10 May 2024 09:03:17 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=SJZhkGyd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=chG26ezu; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=SJZhkGyd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=chG26ezu; spf=pass (imf13.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715331798; a=rsa-sha256; cv=none; b=hM2H+9vRMFMHShMuYT/NuQDOgVZ7F8Qw70UdXGLmBLys/+ljTgNUzEGzCclwBqiaSZvZrA dcDlOarYnshYJKBSdeBJdIsy8EzldahFnjSQPw/JnKLLC8ij/GiSkeQyf6azPgGXxPOaDG IaTkHU+5ilXCCkuLmV1HOgewkheHiWc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=SJZhkGyd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=chG26ezu; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=SJZhkGyd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=chG26ezu; spf=pass (imf13.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715331798; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=v5lrH0WD+ZGBmXZl14GVj4/WGzN86nwR1g9FBI3OEBU=; b=GQJw7b3aQPvfd3tmdAe5c7Mi89OeXRNUdGyPL5pi6m2XDnwL1p4AZ9pEteVhJiRseEHBgp QLBrbbP4B5u4h0swA3Ieu9rhmyfRFsV8JnHmb21l9wUive6oX7MeKA9DBwOagrw+lx+Ee8 EZ+CK78ZVTl4BjBybDssIQE1rwAyqDE= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (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 smtp-out1.suse.de (Postfix) with ESMTPS id CBA653E9DC; Fri, 10 May 2024 09:03:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1715331795; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=v5lrH0WD+ZGBmXZl14GVj4/WGzN86nwR1g9FBI3OEBU=; b=SJZhkGydKcJS2c/m+EkUrA3mJscnf3lcfx+bqnoZx2vHWMWElWlddAHpmW0MQwzpgFoSU9 EhT3oOZ+nA2UjvCSQYHJ65+VN7Ww5RNd4DQdzR2gffKxjyNM5hYtOQJaabybdawstkeB0x betOs2MyqCjJ8aaNIBMDlkd7r3MWWqI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1715331795; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=v5lrH0WD+ZGBmXZl14GVj4/WGzN86nwR1g9FBI3OEBU=; b=chG26ezuNunBPtwF/ldw02eKtzPoibRWRSi/vPftDcZ6rIMP1x013qX45zDm39+2THxuGY /gmVT4b4xQq5wlCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1715331795; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=v5lrH0WD+ZGBmXZl14GVj4/WGzN86nwR1g9FBI3OEBU=; b=SJZhkGydKcJS2c/m+EkUrA3mJscnf3lcfx+bqnoZx2vHWMWElWlddAHpmW0MQwzpgFoSU9 EhT3oOZ+nA2UjvCSQYHJ65+VN7Ww5RNd4DQdzR2gffKxjyNM5hYtOQJaabybdawstkeB0x betOs2MyqCjJ8aaNIBMDlkd7r3MWWqI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1715331795; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=v5lrH0WD+ZGBmXZl14GVj4/WGzN86nwR1g9FBI3OEBU=; b=chG26ezuNunBPtwF/ldw02eKtzPoibRWRSi/vPftDcZ6rIMP1x013qX45zDm39+2THxuGY /gmVT4b4xQq5wlCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (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 imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9A010139AA; Fri, 10 May 2024 09:03:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ViERItPiPWbBLgAAD6G6ig (envelope-from ); Fri, 10 May 2024 09:03:15 +0000 Date: Fri, 10 May 2024 11:03:14 +0200 From: Oscar Salvador To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: [LSF/MM/BFP TOPIC] Deprecate SPARSEMEM and have only SPARSEMEM_VMEMMAP Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Action: no action X-Stat-Signature: jnyygop7psra9kq9919iy1jadqcjbi98 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B46ED2000B X-HE-Tag: 1715331797-504340 X-HE-Meta: U2FsdGVkX1+M0OF/CZlxYAEmSJtVVFXRMaqMa/oeAOmtsEV1Ye7kTfLCPiQFLm0iX7mwOaEXqrenhZlp0yR6XHqRizq0AUA3iNPKsLlORveNeHf6ArceJ8P0KL1YA3flGv1aiNtndZHiYo3oGutgiqooG7r686kY2iRlisiwiVTA0zE42rlczEiXtzLY9bklDcBt2cOueFh7fSg+uz2mE5DEb1fakhVg3xvV0GGKma3PuhU2mvuSDei9rFXFtcOnOrQzjqVnQCu4v22R5l7rF5u1OHkJ8p2KUbd/aEP58nh/yzLnuveFMracDCPhSpbHGH34AsvttzqxPU5CdxfW/LVNEUhyt4YbGU0vhal1eKZGwUBBaQ2tOgX73lQUfMcZmh/WG6JgSYncWEkvm6NDJXWbC6heE5lLUPJGDO6EN9Y4z2vRm//8pYokomccAEY5cxCu36dXW77eIKAGzHLaplDf2Sej07lefmqDbv+J2pAgkaVixBrXmbapFyufHAzMZGCWwCUOCJKOQ8+39+mqR8gOmy59Wz3NeWilPBXpIIxOFx7pFTOSxFWn4GbeD+PGbAha8sG12FgGrfqdA6XMmodVUAALu3Rta1To6wrIhkfE5oYTnQJaQMfyqTEHBTVIfXZ6NaoHSpzlamf0yrTXyx3U54oouAEAeN6AEHD130Nl5M9BpAuOzMN3EU1JZSyI4XuGu4brF4v/WVSVlZw8JZgAnP6sEnz1UXELo0yHnQsmKa9c7HUDYMOyCyCEyG7QkSrV2Fk3Ysv3g8gNhyjny8nENXekv83+t+GJR0KCKYp5G4VwQ+1Y5ZKLS+t1L8jIWPUIYavdqvd/82nr7gjz2WWe39R/KkeSTyhoxdL1rfZUbFuVNjoPQ4IMzpYj0nM8CAy60TsLkEJiYnW9r0vDCWne+lexFcJx2Aso8eEm1czrdJUcd3+wqjsURelBWnIKa/vCMvqxqs8rrc6nKwl it5I/pXj 87CaTYAJ9lKXkRCgCdDUM8P/RAcKaZyi/EBwx0Vuo3MChG9Ug4iJZkvvLRS4thmWtbCZat5gT5GQKx+b1nR3T4hU70ZF936qhG3W4chr1pWeksiWrFEfJR6/z7TgFnruBFu5ANq3z2Ja+Zx6OzONCxhVhJSFJOj2kBUnqfmnZUBx2EdpHwhMvXr8vgvVKwAX9ihXJ3GuoLuxC7xVaCDoruaA0tw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi all, I would like to discuss the following topic in the LSFMM. We have SPARSEMEM memory model and SPARSEMEM_VMEMMAP, where the only difference between the two of them is that the latter allocates a virtual chunk to represent the memmap array, which speeds operations like page_to_pfn/pfn_to_page/nth_page/folio_page_idx. page->flags layout would also be changed. Currently we have (extracted from include/linux/page-flags-layout.h): /* * page->flags layout: * No sparsemem or sparsemem vmemmap: | NODE | ZONE | * ... | FLAGS | * " plus space for last_cpupid: | NODE | ZONE | * LAST_CPUPID ... | FLAGS | * classic sparse with space for node:| SECTION | NODE | ZONE | * ... | FLAGS | * " plus space for last_cpupid: | SECTION | NODE | ZONE | * LAST_CPUPID ... | FLAGS | * classic sparse no space for node: | SECTION | ZONE | ... * | FLAGS | */ The last three could be gone. Also, by getting rid of SPARSEMEM we would also get rid of a non-trivial amount of code. I did some research on which arches use CONFIG_SPARSE_MEMMAP/VMEMMAP or none(using flatmem?). SPARSE_MEMMAP SPARSE_VMEMMAP arc arm X arm64 X X csky hexagon loongarch X X m68k microblaze mips X nios2 openrisc parisc powerpc X X riscv X X s390 X X sh X sparc X X um x86 X X xtensa arm, mips, parisc and sh operate with SPARSE_MEMMAP but are lacking code for SPARSE_VMEMMAP. I think these archs should be the first thing to focus on, to see if we can make them work on SPARSE_VMEMMAP. If we can, and when all arches can run on SPARSE_VMEMMAP, we can think of killing SPARSE_MEMMAP. This is not for free, of course. There is a certain memory overhead because we have to allocate the virtual memmap for each section. Taking MIPS as an example: - SECTION_SIZE_BITS 28 (256MB) PAGE_SIZE_4KB: 4MB per section PAGE_SIZE_16KB: 1MB per section PAGE_SIZE_64KB: 256KB per section - SECTION_SIZE_BITS 29 (512MB) PAGE_SIZE_64KB: 512KB per section e.g: When the section size is 256MB and we operate on 4KB page size, we spend 4MB for the virtual memmap array per section. (65536 pages per section * sizeof(struct page)) = 4MB Ideally, we can discuss: 1) whether it makes sense to definitely switch over to SPARSE_VMEMMAP 2) if yes, how can this be arranged. Implementing all the code and giving a grace period? 3) if not, why? and what can be done so we can proceed. Thanks -- Oscar Salvador SUSE Labs