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 43DBAC25B76 for ; Wed, 5 Jun 2024 22:44:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0C9B6B00A9; Wed, 5 Jun 2024 18:44:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBD8B6B00AA; Wed, 5 Jun 2024 18:44:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5D296B00AB; Wed, 5 Jun 2024 18:44:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 864746B00A9 for ; Wed, 5 Jun 2024 18:44:07 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 27CA940FC1 for ; Wed, 5 Jun 2024 22:44:07 +0000 (UTC) X-FDA: 82198314534.15.1D5998C Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf07.hostedemail.com (Postfix) with ESMTP id 3122C40009 for ; Wed, 5 Jun 2024 22:44:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FC1IzUx0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717627444; 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=gvMN/Z5GD4k1XkOsSbKTKrEEE0iovv/oIigOmpImY8g=; b=QdMk8vyB0vvRHgA7j78K6A6lo4L0qBSAvwKB4LfrPLzNE4dEmzMb+QlcOaNMNwCTOV99nV bI5x06DvbszlsUtCJOUcM2y/UiBdzvB9qZ/r60PtSKnAzuuJfU9J4H5xbQg2OmgX6XsJhi 6KIdB3cIg94KxtGT47uV9soGsEA3gJA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FC1IzUx0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717627444; a=rsa-sha256; cv=none; b=pz/7vAaagf05hEYlHKuM3kxTlsCA+hJGqymjNoADYBHbRdf4HNq3MJ6LvrsHF9P6rXtpj3 QTb8CtVmUb87wtQtn8zkMw68qHo7GpWN4H4RX6gQAIEzTTLjmAO+MkSCHCT4PV8f1UMjiW H8udLBVejMtcyBSIZn9XGgP71JFYHdQ= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a68b5f18fc5so36481066b.1 for ; Wed, 05 Jun 2024 15:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717627443; x=1718232243; 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=gvMN/Z5GD4k1XkOsSbKTKrEEE0iovv/oIigOmpImY8g=; b=FC1IzUx0gLRJqP0SuJgJKNrvMhDylhMtLtCMS+ICxF4raUNgkReFua206Yh/mYUmHj ppxx5BE6uQ+hUBZkb+bZBi0SyD6sjgQXeicc7KjV+qIAnsVDW0mEiLDMAXF6OnbwS2U0 r9OocXrxtb8WRlpBySgoHpX8ZqSqfRoNIT0ekGRzoawQkQgbcAdGb6GkU4vqnAkGKe9T UsES4ytVJmcAN1qJdGLRin/LH1TVu8I0AhrQehQ5tnt/oa0ZhHkci1Euid7tGgIZ7+R0 necArGNCzFvR4SZefFmF8zEl13rt5gwA3RLqR2efVe0zBL52nShN7TL9w9KNBbYPOVpu GpdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717627443; x=1718232243; 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=gvMN/Z5GD4k1XkOsSbKTKrEEE0iovv/oIigOmpImY8g=; b=audMg0yyGU0ww5fWENQW8kTYFpAh5J21h7ej2IfBaa77p1V3FB34RvsU0iCfF5kwEy lO/wAhOBdCB2kih8tG85P0wK8XPYQu/Uv/8M6XMG0m7rhx4Y2u/zI5f7tUy5UGJlER3G RI2V1gp2Xfpeg1JKZZf6RsFBqqd2NnJJfWxlUKic9Pm8yzjMSJetvCP21IGm0l/nLExW cPUFrMHp323zaEZjZ/Kg6sDgKjJpxpxo2ANyWRtEorOk1nTkg11RY4FuYoU6vvZBKNhP JA8EeWsWFpnQQbk+5IcRboX0XfBlXaIflrUccdspQVWpDY3g1auaPPP3OK7cj9YpWMcf j9gQ== X-Forwarded-Encrypted: i=1; AJvYcCXF8Sej/y8pMoDEz86daEMJGwOkvtmhXJYUhF6R/GQ+5yDyovju+epTpXwwe/lB8ngPrln5BDHm+sQpNLjoR6X2h24= X-Gm-Message-State: AOJu0Yxjhc0+G46jp0W1YjrwTvUDS/qJ4pq1nbj5sc5A8ubobBYbRMFV 8aJx2nh/6rQOcENMVtl2sW87/R3cWS8Lkd/1LGYXBOFv6yG7HcNB X-Google-Smtp-Source: AGHT+IETeetH8FrUF9Gtc6rNSOm07v0/Kgl/MDXIWnwhOcAmVPAL9eXEDg6+OWYjd9IEjJxUsUWOXw== X-Received: by 2002:a17:906:66c2:b0:a68:ecf8:9edd with SMTP id a640c23a62f3a-a699faacfdemr242607966b.31.1717627442380; Wed, 05 Jun 2024 15:44:02 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6c806ec844sm1665066b.120.2024.06.05.15.44.01 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Jun 2024 15:44:01 -0700 (PDT) Date: Wed, 5 Jun 2024 22:44:01 +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: <20240605224401.re54hhnlkar5akfm@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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3122C40009 X-Stat-Signature: dmf83mouajpapkswb5wjg6qz89gix6hd X-HE-Tag: 1717627443-709090 X-HE-Meta: U2FsdGVkX19MQSa6XE25/Ah6+vwxOi03kuVGxfQN8CS9BNYPDOf4gOHGyljKBbs0qQHAXkCQe/u54gTWG+R2aDaZQyn6zISbM8VnbP6PQE+/c5zPibdNI19H+DCfyuh0pleDGEokyaiTedEcWGkxvhQXXd4m6BgP7MGnq54jS7ta4wRvT57TRXeGM0eR6qfEgXI7A6+Yl3gU0gnl4+2bP9m6trVdjsPpq7j743fRPUTlriTJhBaQP0pHpLQ/wxm1C7XGEhG1kywJDFe5W6zJCdSGpTYZEMH5cq0w6FLTmsDBltGMD3b5zmgYPT2snvprP3IcxpNuPCPvpNOJqVSLIJufJCknlwIKXZnvkain1N6W1Xa7DMEwFRZh9sJT/YLjMywym8cAMEFNPFLoCLV/FwktDLoCZNZMtRC6L4Nbr4MMg1X3kxBISRqv35WwCJ/JRpTX/Lrs3rpTOJcUe75e73v463r8mbB6FosQdACytstI+4nG6z+r/qDJuhqEO8kBPOJ0mB7tWN3kszhQcEqQs6u8vA4zu8b3317K0ZK/9tqv1kpMZl6+PhWqBAHa9s+6ZuKr7cBdHWceISOynsnqv5gGiJWLe4sRgYhtpHKHhoOkgkhcSN55PWcdA7E8KOYK9piZL/QJdNUmtDiOu7GA6JwB+oN+w6M7uNgVH/T9e2/1ZU/kYrtPAm9meH6G7rKYGvKnp60ph2v6O/kuh0KZ4P3P+r3hRYTHM6sW/KTZojZp2PmhFoUSenRmc7+vs2ee8vZdhD1Eo8mNiE5oKq/Q7IGdqm9nmF5nhxToeSmlVbucfkqg+kSCDKTVMIvSOBF4KBK2rbRPTmTZkaUidBkjIM20bYoBN+69zK/ZORp/T9JCuzX9AQjId9JRpTwgwrEw84r8UMSUP7IkDFD1/7R46ML6qHPhS3JJgZTatLemMV01Hu76juzAefWJ/ZIEPqVXsYBItihQ8TvqExonMso GEWNKw1Q 85RWdtgrFVvSQLyxZLCsLSdCGGOqsE4s4nbyy4Jqy4bWLE3DSMzs80IafvmaApA1wuxuqetyZ86V2GdPNXurv2TjFdbKPshsC9WAoDOOaRmT81dGjYhorrlRWaeF0fmzZ9vss1SYxFEsbXb1OWG4E0vE4tU2nP91G38tRJit+NjV5rsMByehDpKBhp9d7lgg4ByEpHQ9uHcsGUFZIFZmqkdlzGT0MijkQrdb3eeUh9iC7IOd9HsPh6KO2lDvh7pvrINzj5AdIzeL2IhQsCQiIO4FKTXSeR1+kyPflWAuzhspX6UpIZwNaLMFHkVSkM73OgF2fthDlDJjpipfboUCOEJG8lX5hI+2tNuV9HOwKewVus+UM6/sV4v6PcuIr7PuMl3bvXVHWslJX3xEc9wm7epC8TCgQ/4XqjE1TB84H0MIsZjgkLR8oKGuHjMBNuNI3P/UQx6QEibJyKk2Xh2LVXGqekYrsAR121YPYatcd7gLHeHDzq7HK2MfKg0nWdGKI20UPGhbDoGJ1lL62Fo/7ErZR/ZDyf0TTflJ9kmFiPTqiVRAbqyC+mRh9Z48UzYuwv9ReIs5TbZObFJrK4bKTb/8a4fkoS6TpSRgquiujJXhuow/nrTCo+MnEgkZsRs697pi9sXWChsVqvnLf/2DlUpChBUe3sP6HK0ABxvaZ3/lLTjVoF7O3UGdE2r/M5cWNslL5zAe+IEv9RH4H4UdP9RBXs93oH++1yDRHPlJNpIWgi4s= 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. >> > > > > >> > > > > > After the >> > > > > > introduction of DEFERRED_STRUCT_PAGE_INIT, it may count the pages before >> > > > > > being managed. >> > > > > > >> > > > > >> > > > > I recall one reason that is done, so other subsystem know the total >> > > > > memory size even before deferred init is done. >> > > > > >> > > > > > free_low_memory_core_early() returns number of pages for all free pages, >> > > > > > even at this moment only early initialized pages are freed to buddy >> > > > > > system. This means the total memory at this moment is not correct. >> > > > > > >> > > > > > Let's increase it when pages are freed to buddy system. >> > > > > >> > > > > I'm missing the "why", and the very first sentence of this patch is wrong. >> > > > >> > > > Correction: your statement was correct :) That's why >> > > > adjust_managed_page_count() adjusts that as well. >> > > > >> > > > __free_pages_core() only adjusts managed page count, because it assumes >> > > > totalram has already been adjusted early during boot. >> > > > >> > > > The reason we have this split for now, I think, is because of subsystems that >> > > > call totalram_pages() during init. >> > > > >> > > > 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. > But deferred_init_memmap() will spawn threads to do the work. I am afraid do_initcalls() won't wait for the completion of defer_init? Do I miss something? >So maybe it's not a big concern and this separate totalram pages accounting >is much rather some legacy leftover. > >> >> > 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