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 D60ACC4332F for ; Fri, 3 Nov 2023 15:19:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 693248D00C1; Fri, 3 Nov 2023 11:19:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 643058D000C; Fri, 3 Nov 2023 11:19:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E5788D00C1; Fri, 3 Nov 2023 11:19:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3CC718D000C for ; Fri, 3 Nov 2023 11:19:34 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EF919120F77 for ; Fri, 3 Nov 2023 15:19:33 +0000 (UTC) X-FDA: 81417002226.03.ECDEBE3 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by imf22.hostedemail.com (Postfix) with ESMTP id EDC13C0007 for ; Fri, 3 Nov 2023 15:19:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=cGgCbVyf; spf=pass (imf22.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.181 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=1699024772; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=liLeXSkpooaWOUPaSwHhbbjwtzRLYBJW04zYO+tuOmo=; b=iFUvPMR97Vd34MfjtglGQlQGAlILZsgo+NEUOt7T5abq8UGCLMOlvlnxjuIQJfgV6XdIGl EHNoBp3rioEmhRsfivV89j8em7m1Jb6SAgd5n5NHr0Fvj1bWc/gbRTZxym+6AyiPj2+ThQ 2b54egMzL7+eK5ZPwdxzlPKUGBtgr6I= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=cGgCbVyf; spf=pass (imf22.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699024772; a=rsa-sha256; cv=none; b=Mio71pdCZWyZNjDtJ7vyFcKgPFopSaRfGk+iG9imyJSW/MQ3h3XRHsGGI9Q134MKmPYaYt mKDtFRmguszrMsi9r6n1aUaQC/Z+PH7SeC5/IoBPuaTGXdmKlaxhJqorl/qUct5DiTwqlH MvEjj+HrRtoDlIMgQtLrgBjlP1zmyrk= Received: by mail-oi1-f181.google.com with SMTP id 5614622812f47-3b2ea7cc821so1320516b6e.1 for ; Fri, 03 Nov 2023 08:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1699024771; x=1699629571; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=liLeXSkpooaWOUPaSwHhbbjwtzRLYBJW04zYO+tuOmo=; b=cGgCbVyfl8HeU7NEOk33fFsNeCLkvU3/9y4v9sd6qnuqpfgerOh2LnyEGCClRdOmPE U8OhN6zCxNF/gC4kQFLGm88KZZhpBeIKcDe/SoGGRNuBdxNoFl5wjDt9tePez8rDtvJu JZGRBEe+UCx/cM711geOgP2djzvij0PWUxF5XOqwr4w/YvXvj28g7lvjqm3k7LniFTGQ 4wEFzaAGNRjFkCBwYioBn1FUcWESwJ7TcFrmxePc0P8qJCAgQafsJaJsw+J/ffLtK9XF tuaTZnzeqGj29XN/AFAN0MTUrzloq1hO+on9MhOfhLwTPoliUVa3CjbmgJRocV0hhrgX uJvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699024771; x=1699629571; h=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=liLeXSkpooaWOUPaSwHhbbjwtzRLYBJW04zYO+tuOmo=; b=jpzUt9cT1xuGTIVn9OMeb7t5BUkXt1F/+CpFN5WmGHmAUBV0eVOO0mchJAWIV89IkG AFOdrhc5YIfVbpwMvnZeCj4CklzjGJwVLC9jAqGFkjYqh235ihtqYSxMdjLLhe+kmhCR ae8w+IpRqbtebtXXMPYez6RVzlfZTE8zYy18aI07eRr/ighZ8F7xA536HOZ0JgdHbr8u aEe2MIAj9xYfcI8H4h33/o3otIz4rwdJvAnwrZBqr0Yxza4VoGjGqrlgI9V2QAe785cf QtZofS32rHsHSVafpcrGeMT8g6ySmnEbo6LaAacZ0d26LAvclEK4meQmsk4ywSNdr8MP DbJA== X-Gm-Message-State: AOJu0YxTPf9UL85wVgVOOfYlTlzH2ndY0m6XTyIR9rEFvWbKvC486rqR Vq20U1VnR+DJpZlN/S45J9RKwcrWj/My51yhWK4Bow== X-Google-Smtp-Source: AGHT+IHPzOa9iAe+GlV7Tg9JGtkM0A7QgdUDBavOwv9+9DuGS+xM5/s6EzR1YL7nknthcj0uI8QJut9DydQ7Bvbd21w= X-Received: by 2002:a05:6808:1986:b0:3ab:84f0:b49d with SMTP id bj6-20020a056808198600b003ab84f0b49dmr26946069oib.3.1699024770996; Fri, 03 Nov 2023 08:19:30 -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> <99113dee-6d4d-4494-9eda-62b1faafdbae@redhat.com> In-Reply-To: From: Pasha Tatashin Date: Fri, 3 Nov 2023 11:18:53 -0400 Message-ID: Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information To: Wei Xu Cc: David Hildenbrand , 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" X-Rspamd-Queue-Id: EDC13C0007 X-Rspam-User: X-Stat-Signature: 5foygjj3h6bsyq9byqir5zynowcmazfw X-Rspamd-Server: rspam01 X-HE-Tag: 1699024771-43376 X-HE-Meta: U2FsdGVkX1/ycGCBBXGcu8wvfZw4Wcszbki1URRX1mFeOANkVLxbfm1r2Hb88fYv+sVHSVnkCaSnYuPKv8WZYlZmtf5lQI/w5Ort8Dh7g+kQ4kl6xZGXWqvzgeAno4jf78Z0okdMinEuWVbiTAuZLmoUM3MZ3r1Sg4y/ZQD0814Vf7X9jf8s/sDRLMBu4yXt4FVWjnC3ncluivIlRI43cndsJHjcv4DciIJ7CZYB6W3oBlJ+M5QKM4lKLuFLBye3brLXwsp8cTuTJ7gMQ2a3uvojOLOS9fmEaDpSGacdoeCKh/dm4Y9BduKx0yxUi7xm4yqrDOOCzk3Wmy8LLDjk4u516rP+8GyKbsLZpGwovKZhMgbcp/tLbIDlrf0pVJWQ2PEo7g1jYxmimctXmU84ZkM/lgxY4yu9WxNneqxnFyhubh2MC2ov/5wxB44nczp1Dw+8xcfcqfs2LCEtk24SVg0rXLmQ1T6B4EOLMZYJM7+wMG7GD0kVCwZdrkteIMtoA5LViUUhHz+C8kXCiDmCNyMCum4YGE2t+om1Y3fcFYqE04XpVn4MY2fLKpjrJHfEEjFzoau7T/eyJz7Dopfa11oPg8CX9WiGSp+23Eik866dj3FZG2v2A3+Jj9FXlDUzoSZbUa2TP/1Coz6u6H3l5WK94O70zR4cn8HrhsK/Yq0HRxLFddc7jlzyBu/YwsFk843iZL6vO7wc5IQtB8/FzyOt+dGH/ke3kfa8q39sFn5SysbqPhh8/0qb97mDcfMt/uuXVHwDp0wiupoagG+YZeIPJApR120hW7HhTKdJPVoel0ARFIlvcDAp1aDLUVvby5X9TbA3o940Nrru2lnwdDCRf6LevQHKwDyoURkmhMkinM3HcSSkKiY3VCa0+PWJMf4teqtqe4stxNxXtGMCtj/mlhQlkaT7V/t2fJ2K/ljK88EMPymnRi6DELp07RQZDHZWUUStYC39tbEr/oq 4asMY7+K 6a0F+9rLWZGrYtv7brxHENh5UKQA0JREzp9trXumNb40Ih3o+xhfUfsVRXJ5NywLeJ5Ba2ajqGZ+EH5wDKsYxsErUriisK3jltMZk2HVLWqGOCUusLbb7yHHV73KSQ1CyMht8Yp/5Dvg0DuTATC0Lr5oW0PqX8pTpph6GMzzKL34H1H3IT1hZP/FBb/CkDZT/14F5zmUo5h7V1Pl0Sk0Mhn4TZw7yKxoF0k8wRZz8OQ+oE+5HRTw6pjpP4QAkEMywIHzHGm21lx2iakqoRaUYXIzSMA== 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: > > Since we are going to use two independent interfaces > > /proc/meminfo/PageMetadata and nodeN/page_metadata (in a separate file > > as requested by Greg) How about if in /proc/meminfo we provide only > > the buddy allocator part, and in nodeN/page_metadata we provide the > > total per-page overhead in the given node that include memblock > > reserves, and buddy allocator memory? > > What we want is the system-wide breakdown of kernel memory usage. It > works for this use case with the new PageMetadata counter in > /proc/meminfo to report only buddy-allocated per-page metadata. We want to report all PageMetadata, otherwise this effort is going to be useless for the majority of users. As you noted, /proc/meminfo allows us to report only the part of per-page metadata that was allocated by the buddy allocator because of an existing MemTotal bug that does not include memblock reserves. However, we do not have this limitation when we create a new nodeN/page_metadata interface, and we can document that in the sysfs ABI documentation: sum(nodeN/page_metadata) contains all per-page metadata and is superset of /proc/meminfo. The only question is how to name PageMetadata in the /proc/meminfo appropriately, so users can understand that not all page metadata is included? (of course we will also document that only the MemTotal part of page metadata is reported in /proc/meminfo) Pasha