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 A607CC27C5E for ; Fri, 7 Jun 2024 01:50:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3634D6B00A6; Thu, 6 Jun 2024 21:50:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 313706B00A7; Thu, 6 Jun 2024 21:50:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18D8E6B00A8; Thu, 6 Jun 2024 21:50:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EA9886B00A6 for ; Thu, 6 Jun 2024 21:50:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AD487140A3A for ; Fri, 7 Jun 2024 01:50:14 +0000 (UTC) X-FDA: 82202412348.02.70D0D30 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf07.hostedemail.com (Postfix) with ESMTP id B8A654000D for ; Fri, 7 Jun 2024 01:50:12 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hCH1l8yK; spf=pass (imf07.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717725012; a=rsa-sha256; cv=none; b=L1qviPspgq3avFspRsGic8minPbvKkziKgEK7u6xh/ty5Ko1KdAoNVO5QoMHDtXIsJJumI ceH8Xokrp+lHlN0w/uKQ7iNXaMKzQewm0K8fiphy0z0byLK5B7zm1SYZUnHJr3J07bUeS9 JweYSp7cF9p/qscOEAHNq5S3DrYyPi8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hCH1l8yK; spf=pass (imf07.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717725012; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yZfMhWDwIy5kUygyKrCwQZcQSRvzQxYrydncD4aOCBQ=; b=qkPHIeiAKBwthFkM7wxswpcHqBkUxgZ7ywxAO4IfJD2v9xLPO+Y+GOEhaWJW9Qy8q0xG9B wFLeZkArPDjqlFC8LHRO7iztYPjXttIFuzhCoPA/aaJ9fjr9MGm39yMgD85q9kitNDLXDX dNARMruo+/LBtZdUgGbm3Gkp+/MPiM4= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-57a52dfd081so1787765a12.2 for ; Thu, 06 Jun 2024 18:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717725011; x=1718329811; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yZfMhWDwIy5kUygyKrCwQZcQSRvzQxYrydncD4aOCBQ=; b=hCH1l8yKROH/ZeCz2ycWP1jIAlj1s7qDc+WYWS4ZBIlwL3CeqpX/ij7xMnVv1IzNYu ajpVtKtekDjVgwTQpSS4wsixcClksq8pEsWMWUaOwn9bAna8Nvo7vVnEHQ2pUGVZHwh2 Q427RPI0tCOyQfuW1ypOHTK5cEH6CSb95MR///+Xcpzmpo0LzOd5RHFQ/42yvaJzIMLP d4IYnelSAayMQWqlXvavplqTpB6imT/nNQ26Avgc5tJtOzuVhCgxgg2aDZrgNXozjxfo fB9cCYK9F5Ctd1ujg+vKy2PFj6L1lemhiGa/MHIyhJQvaYlvwp2dd1VVxqzTgflItJyA njIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717725011; x=1718329811; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yZfMhWDwIy5kUygyKrCwQZcQSRvzQxYrydncD4aOCBQ=; b=LQZHdmoMFajJRhYFrBFo/b6soixyCwf3qQszNEr9TPiRVaWq9ooss0qjBfZLIjtLpH q02lspbYyPagSujmvXPSeZzykJq2mVxPMeFT8/oriqC/4GXhzx3Ix6zmqgID7vn7c1mh 3haGJWnxNtiPi4/pky06TUtkn+jEG4gFusf3bbTB2TslEw5xCEHX7sQmLclIwojQSx/Y SF0Jnb6KqOx2874drkkm8iXegTCJYaOFu+Sry0FDWNuem9Muekcpbi5C1pBilNDsFmH5 NCsrdvJduwNxB/mh3+j6gsqYjVuftBks2QKuDX5af93yKizG5lWEMqqyDQ/5ftcYdwol HVEA== X-Forwarded-Encrypted: i=1; AJvYcCUH5bP/QEWOoird7P8StdJR4Ix+1EWGxUas8vULsy4bp0mfbjyZyS49Q8pl1OdsIqRk+iGtOf+toTtqiDfOMhO1CR8= X-Gm-Message-State: AOJu0Ywg9NINwqN5HW6U1xwYgnT6rkKFt6jnRKAeEquVheeoeEKrois6 tPwI3JNR1Wsgy+JCGnABUAgt1t3r/jupZ+sXRv1N3PwVmUyY8ASY X-Google-Smtp-Source: AGHT+IFC/x+zrHNz9M27L8b60p7ptLawGMHPtf6oVlwiTC8D8R1eEgexY90W0GtmapLuhoMeev59LA== X-Received: by 2002:a17:906:3996:b0:a68:f162:b9b with SMTP id a640c23a62f3a-a6cd6f0084amr66035466b.24.1717725010830; Thu, 06 Jun 2024 18:50:10 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6c8070c287sm170457366b.143.2024.06.06.18.50.09 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Jun 2024 18:50:10 -0700 (PDT) Date: Fri, 7 Jun 2024 01:50:09 +0000 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , rppt@kernel.org, akpm@linux-foundation.org, osalvador@suse.de, linux-mm@kvack.org Subject: Re: [PATCH] mm: increase totalram_pages on freeing to buddy system Message-ID: <20240607015009.pedrpgwtbt7drjkx@master> Reply-To: Wei Yang References: <20240601133402.2675-1-richard.weiyang@gmail.com> <0316a276-a0d8-4fc2-ad67-0d4732b6d89b@redhat.com> <20240602005820.2uk23ot4mskfl5sl@master> <8297c4d3-f97b-4923-9b27-19294fa130eb@redhat.com> <20240603200123.bvkttf2yqutecjtv@master> <9fa4f1be-790c-4823-aff2-f864807759f1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fa4f1be-790c-4823-aff2-f864807759f1@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: B8A654000D X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: b7oq77pfugaqxrs5g3rkbjokrjyajn7h X-HE-Tag: 1717725012-875317 X-HE-Meta: U2FsdGVkX1/HZt2+Yt2W9NQAXg/B8fs7Yr5H1TNyEIznOkJQ5m/FzJCNO1WRGv+1tGPPgmlA6+TvueLdHm8uxiU3LYMv35HJ9YdjH24CviPzYJRHnfxD3SrtGIOEyYvB6vUen/nq1AuNmGlDEOeBkY1WJHiLuZb+GpSTb8Yh+gMXP/v1SpJuBeqk2LM34qXhMmcHP4xmY5/lsJKQuOQSBRhnbvpOIqhVpKB0PBi0PSf/HjOFVOhCepQ9hfFRTdveytB6GR5/MqECnmmlWTivLuvLktObswt4gjbtrLhge5VmiEB2T8WsB9DqYI95O36Y3vB4Xns1tq5fzqW81D/GV7Tcb1CMxoaJrYtVaz6KPH0bfCQoxyKj+S9tOKfEJ72WSlw+19bwgUTh05ksfP9AUfg89NEVEZc/H6sG/IPnnZE59OcP575CM0CI3GYHVSrNHCuDwr/ePVgX6Nu5l9q12+HAcUKyD4ZFnsd8RfSOIh/WCnqnEkbC0FBNSS/s9rtVg3He9QiuTHXQOX1PrPNMFKubmWP7EwbZi6TUNduA4bYZU6x5oHC05+OX5NTtlV12rjaF2YMLNJPexUFLant5n6M323U2a3evOuvGfkt7sTd6qAoxT40weAfoJViFx5E5Wh5ZekBesDxAj2CbGVd9mDe1KAU4CyWfZoVqqmHzXTUwC6nww7BQNHp2HD+isBTEZO/Xden1sUSK+Jv6KmbfLiS03d1A9yWngMIuoqBiPoHdyhpKxI4K6LL+LRPJnpTa8iR0kwzroJPCKm07FLyz85GCGYAqroGmVq3fPlbGt/MLocE6/poX7NFk5aiUgVViI0eXZtm73iqirZbQC1BE2pD4Whp4tvmpvSjOxgEPXJjLJ0DPFQcchYlTHkbkaq5+jW0SAcfaXeJ7lTvDSXc871U2wqAFpAGV6CQtIDMb9pNz2uqfpXGBlF6pVJtHBmTJ8WEN0QRr5a0rqGQkYTq ifINUfS6 6kYgmzqdSvnV6fy8/DrtEiLvelEO8HVYrxc+S2IfnLJrwgsO2kPPBctrFVP4vD0gTuki8rWLmmGNCvpri7zaBn4XNwvg9mv8NJjA9nzmqJLv+Gfo8/TtUAjzakaYriDtpZ5zfG9ATs7z9bRs/+ZHqVVbUntbkEA6dwCzMCB2PeuzmFw0RASx0QhJZ5qk7ZxCEP3UR8B53ntqgIwIkIxwA5PsOOd/TqCdl6kVQKnJfGFdc9orS0Yr4sVCLuUw87sGDJ99v5+fq24HbuAAjmLaHM89+qfU0Xj3O7ZOTR07eh65WyTQ8F+TXXIm1JEsoGBXDqFffIOi5woYffgEkAjCiEvJtN+1WgLFktA2a9e0zblt8SnJ76s7fW+MD0wIcJuWQmZp5RaJTlycqHYajpXmMK/m3UlJw2t2O2e5NZWzzCZkhdKUAbNcS0gBxxbygtHE1US8Dn4/k3e0/6ugupN9kHPDcLEwAHMzazImYkyP+LCghoeKA7VEQrcZcmXmKWA49Tcq09Wyh45VaDAwBikt9VBGWkbjAqRiFrEJ9beZCT1ZmBjd4pR7pHQyr3g87IHW7xfyaT1CoPbT+6Flfhyj0jBb2JvcmMIQhacSEroVq+JQKaRXYWdLcQ/7jpCYwN5QqNLG0zd2madfHKEPB0KdtO5mKoz8BmSOhJnGq4f6U6GLkhX5vHGi+U2lGure2aBVLgDzN9zoH501z6h7fpYAOSMDEVXD+2FqWPmdmWhtVk1Dxk78= 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: On Mon, Jun 03, 2024 at 10:43:51PM +0200, David Hildenbrand wrote: >On 03.06.24 22:01, Wei Yang wrote: >> On Mon, Jun 03, 2024 at 10:55:10AM +0200, David Hildenbrand wrote: >> > On 02.06.24 02:58, Wei Yang wrote: >> > > On Sat, Jun 01, 2024 at 06:15:33PM +0200, David Hildenbrand wrote: >> > > > On 01.06.24 17:32, David Hildenbrand wrote: >> > > > > On 01.06.24 15:34, Wei Yang wrote: >> > > > > > Total memory represents pages managed by buddy system. >> > > > > >> > > > > No, that's managed pages. >> > > > > [...] >> > > > So the "why" question remains, because this change has the potential to break >> > > > other stuff. >> > > > >> > > >> > > Thanks, I didn't notice this. >> > >> > I think having your cleanup would be very nice, as I have patches in the >> > works that would benefit from being able to move the totalram update from >> > memory hotplug code to __free_pages_core(). >> > >> >> I got the same feeling. >> >> > We'd have to make sure that no code relies on totalram being sane/fixed >> > during boot for the initial memory. I think right now we might have such >> > code. >> > >> >> One concern is totalram would change when hotplug is enabled. That sounds >> those codes should do some re-calculation after totalram changes? > >We don't have such code in place -- there were discussions regarding that >recently. > >It would be reasonable to take a look at all totalram_pages() users and >determine if they could be affected by deferring updating it. > >At least page_alloc_init_late()->deferred_init_memmap() happens before >do_basic_setup()->do_initcalls(), which is good. > >So maybe it's not a big concern and this separate totalram pages accounting >is much rather some legacy leftover. > I grepped the whole tree and found following 4 points may need to adjust. Hope I don't miss one. * arch/s390/mm/init.c:73: while (order > 2 && (totalram_pages() >> 10) < (1UL << order)) * arch/um/kernel/mem.c:76: max_low_pfn = totalram_pages(); * kernel/fork.c:1002: unsigned long nr_pages = totalram_pages(); * mm/mm_init.c:2689: K(physpages - totalram_pages() - totalcma_pages), * arch/s390/mm/init.c:73: while (order > 2 && (totalram_pages() >> 10) < (1UL << order)) mem_init memblock_free_all setup_zero_pages This calculate the size of empty_zero_page. Not sure if we can postpone this function call after defer init. * arch/um/kernel/mem.c:76: max_low_pfn = totalram_pages(); mem_init memblock_free_all max_low_pfn = totalram_pages The usage seems not correct. totalram_pages return number of pages, but here it seems need the pfn value. * kernel/fork.c:1002: unsigned long nr_pages = totalram_pages(); start_kernel fork_init set_max_threads Not sure it would be fine to set rlimit again after defer init. * mm/mm_init.c:2689: K(physpages - totalram_pages() - totalcma_pages), Per my understanding, we can print the info after defer init. >> >> > Further, we currently require only a single atomic RMW instruction to adjust >> > totalram during boot, moving it to __free_pages_core() would imply more >> > atomics: but usually only one per MAX_ORDER page, so I doubt this would make >> > a big difference. >> > >> >> I took a rough calculation on this.One MAX_ORDER page accounts for 2MB, and >> with defer_init only low zone's memory is initialized during boot. Per my >> understanding, low zone's memory is 4GB for x86. So the extra calculation is >> 4GB / 2MB = 2K. > >Well, for all deferred-initialized memory you would now also require these -- >or if deferred-init would be disabled. Sounds like an interesting measurement >if that would be measurable at all. > >-- >Cheers, > >David / dhildenb -- Wei Yang Help you, Help me