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 CB431C4332F for ; Thu, 2 Nov 2023 16:03:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38662280001; Thu, 2 Nov 2023 12:03:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 336AC8D000F; Thu, 2 Nov 2023 12:03:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FE4D280001; Thu, 2 Nov 2023 12:03:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 135748D000F for ; Thu, 2 Nov 2023 12:03:34 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C5AFA1CB0E9 for ; Thu, 2 Nov 2023 16:03:33 +0000 (UTC) X-FDA: 81413484306.10.D98AF59 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf01.hostedemail.com (Postfix) with ESMTP id 9B78D40014 for ; Thu, 2 Nov 2023 16:03:12 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=hfTHV1Lp; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698940992; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ALiAo4buXiADi7F2Q23wsqEzCK2Th70JCnzOvrzRQhs=; b=JW7lRttdhkqZZheru0o6fG2LhRoo8M100jq5/w95/smNtdJlQVjJkywkND60f0OzucA3Bg lILdkcEeMZpQEElZ2ElwIVznXmGQZU+qi4vAvJEdc2EEXistEe/AGBJ30Sfjlvq8kl+5ih B/ppLsawLosGqBV4i7ze3h52GL0EHcQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698940992; a=rsa-sha256; cv=none; b=REVwvBmRlAtIEmM+bBVjAAycG+/zK/IH/3lfmtlgf0f6JjN2e7q3BlY/OdF1e0nhagafU2 CzoTf5wnoJcGKBH8xIhiyl0ke00FiaFKt5XFlrftBMwYTgL6ElDDifUTttkH3fVkOAsb0j KeouScuT1hCsTPgtD/bs71vigAGFpok= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=hfTHV1Lp; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-41cbd1d7e04so5922161cf.1 for ; Thu, 02 Nov 2023 09:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1698940992; x=1699545792; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ALiAo4buXiADi7F2Q23wsqEzCK2Th70JCnzOvrzRQhs=; b=hfTHV1Lpr2Bln9A1QQzkr2rUrDpldreY3XoshX0HL1S7zVCuhoc0ODRGv80V3XMHy9 5Pu3lzCfGuicAqRCGxgAz/yQG3d0rlv08yR7PBZuUbht6gxE7WuiokGJ3ZtfzYDDonh/ 1PFOEJmsMGjTXDM4zW+6Kbyt7/Lht4V8/96rgPjmYfLkUmOdY4dXqTC8nICzYJpPRLbF px982ufO8ffcgS96s4U+fFLUEUVewXGTswAJ6GBobAzd/+NXLkQ0k+CRJwZ/PvnwXmE8 04HJ3uDJmZQYtlL4gdkUMnOOu1KOycHqqr0ZahB3E1++waI9fZU9RbvyFxzd+k1eUB3A euhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698940992; x=1699545792; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ALiAo4buXiADi7F2Q23wsqEzCK2Th70JCnzOvrzRQhs=; b=r7mcCyd7fk5786+qPYY1LwjisiWXRUJwvQO2uCyxL5g+zyoDuRXIUy91UoDEWx4Omv bP9f34hcK7pUDZtvnY3Vc5WgQOoPVh63S0/K4Wtmwih9lm8rbvsL9FSq2BvTKBu9p5xo n3BcFBpP4BmmAccNlysCCnff14yRCjv4WnFhVdj1Eao1o3YEF8Mp59h9YycwF0CacIOC wCZwUyq1vb209ULyGdp3zssfLx8ZdVdAqhN/y2huDKi6zAuZYmpMtD3u6h9+7hjo38j7 5O1ohYexw8viiudwJk52VxqKyfIPnmDUkWSqHUQSmW2EB6iYrpOpgvjuLwG+C7qfB8Il jkdQ== X-Gm-Message-State: AOJu0Yz60HFHH/AzTwNYrkwHUhgsK+7Rxo2/lzTq9UuFOBFxHIrW8s+6 yDAk4THXusrxH03Ed2WLIZbo95F6W7wb9uU3wTH+sQ== X-Google-Smtp-Source: AGHT+IGtgUg/B0VGGppDeKhvpeBVvLkJIak1rPzXdw9Ov5a92DYkvep/G1D8BjVyG2BXYDhpoFjsmcCqXXp5HGqdRts= X-Received: by 2002:a05:622a:1a16:b0:41e:280d:4e28 with SMTP id f22-20020a05622a1a1600b0041e280d4e28mr23844567qtb.40.1698940991420; Thu, 02 Nov 2023 09:03:11 -0700 (PDT) MIME-Version: 1.0 References: <20231101230816.1459373-1-souravpanda@google.com> <20231101230816.1459373-2-souravpanda@google.com> <1e99ff39-b1cf-48b8-8b6d-ba5391e00db5@redhat.com> <025ef794-91a9-4f0c-9eb6-b0a4856fa10a@redhat.com> In-Reply-To: <025ef794-91a9-4f0c-9eb6-b0a4856fa10a@redhat.com> From: Pasha Tatashin Date: Thu, 2 Nov 2023 12:02:34 -0400 Message-ID: Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information To: David Hildenbrand Cc: Wei Xu , Sourav Panda , corbet@lwn.net, gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, mike.kravetz@oracle.com, muchun.song@linux.dev, rppt@kernel.org, rdunlap@infradead.org, chenlinxuan@uniontech.com, yang.yang29@zte.com.cn, tomas.mudrunka@gmail.com, bhelgaas@google.com, ivan@cloudflare.com, yosryahmed@google.com, hannes@cmpxchg.org, shakeelb@google.com, kirill.shutemov@linux.intel.com, wangkefeng.wang@huawei.com, adobriyan@gmail.com, vbabka@suse.cz, Liam.Howlett@oracle.com, surenb@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, Greg Thelen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9B78D40014 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rsmuw1xf1b1e8xr7qcimyk8htkc5kdep X-HE-Tag: 1698940992-846956 X-HE-Meta: U2FsdGVkX1+vT/nSm9E1fnyfIwg+9opRbm3ThlNoM0FjCzFSIqqy6vzn95uI794pmUE9Eq6BTv8MZHIGv39HzVPjE1D78Buf5WmbbUrNbYbx96IO8yaQpPugjMPD5EOiASoAfLvyShBXLIyVQ112y5LfSkrZ3Ytcq/7VGkjNCwN3+yIn4TJTH8uGA5GIv/eUTFi3glci69gzLpTVVa1CIKCEJA5LTOebXI3JApPgiCCJEoFdNZ2gx4tOobIjS++5cmzEShmqzUqz37FGC6CuduLvOQn8P+SKfLBlZqevhOylarQQoprxjgBMpw3YTaW/rteFeKUylH/oJyX7yOGtpHr3daraYH4WEClT2+klbn2T5vIxJOyeuOgQnlpPLBhpxufChbinUymoRyFfNjp8HC4/JVTvhcRq47wvng08rZZWTZGj1BMX8M4jf/8+LCvgtQiYkSUdzyM4o3AdDLV+oGsUwYOgigqkC1i8YIdBnxqKR/Q1AFNbZaoOpxoMpnKaYKTT/l1ILrbspUmiJKHmZEdeWiAHU7QqBue3TLDgoFzvbP1c7k++Hrprxu907/DQ7J7GckWHV/MpKTFepOMRXCsd4geOb45KgmCtABYoUqK97udIFXMODmGMCP/HUP3LHrZcELHUL//uGPPbm8dLW3kFx5NE7WHuASKOkoY7LHrngNceh/vz8uE6LaeH6J0LW0E7OXz/oDPIgJpbiaxpxI/Uo04P50STN6OWwTkxZIalTGDPDktKtOfvtSf88mP/HRWeTwsmNB3NIi6YmzwmoPvF/SJN9zY9admRrh4RouPxkQn/vy1QtmSNxUPS4RWqHU+GzwhxqTlLRXFuGppqFFJptjetTIkcYN669pTWzB7bigIOOolrn24FlYY3isqMfb9Dr7LP/Cn+JROOM04J1VpwI9XaO+IBMasgnehSG+bz5kuzCe44gjlsYx4xRCynRbs/sez2Hv916Q3Ln3R t26uCF3h tosQ+ueZTmryZOdlDblWn8JwxelMka9z42/85rzdjSA56qQ0o4Xxl+N9Uh55riicNXKB1JsixNPZnn8TbjpMNRrS8ECzI2NX6VpEGCtMlOYELKiROxPv9ehV7CpUfX+cbTKSa9QCPK1To0bvAxTMEsXAOB3fNFsuXGsv5lh8wvOsMUEMzaJDqXGhWJMD5jRCutxcDzbcHZYLMfK5QREi8khqGTsqRe0yW/gf7HIzZTCEE2V9krDdKwlgivDTN99QZaF+qvwJbOtXCQbelIrn3d2xxjUUPn+irVVCErwt22+/A66s= 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 Thu, Nov 2, 2023 at 11:53=E2=80=AFAM David Hildenbrand wrote: > > On 02.11.23 16:50, Pasha Tatashin wrote: > >>> Adding reserved memory to MemTotal is a cleaner approach IMO as well. > >>> But it changes the semantics of MemTotal, which may have compatibilit= y > >>> issues. > >> > >> I object. > > > > Could you please elaborate what you object (and why): you object that > > it will have compatibility issues, or you object to include memblock > > reserves into MemTotal? > > Sorry, I object to changing the semantics of MemTotal. MemTotal is > traditionally the memory managed by the buddy, not all memory in the > system. I know people/scripts that are relying on that [although it's > been source of confusion a couple of times]. What if one day we change so that struct pages are allocated from buddy allocator (i.e. allocate deferred struct pages from buddy) will it break those MemTotal scripts? What if the size of struct pages changes significantly, but the overhead will come from other metadata (i.e. memdesc) will that break those scripts? I feel like struct page memory should really be included into MemTotal, otherwise we will have this struggle in the future when we try to optimize struct page memory.