linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Wei Xu <weixugc@google.com>, Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Sourav Panda <souravpanda@google.com>,
	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 <gthelen@google.com>
Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information
Date: Thu, 2 Nov 2023 16:47:38 +0100	[thread overview]
Message-ID: <1e99ff39-b1cf-48b8-8b6d-ba5391e00db5@redhat.com> (raw)
In-Reply-To: <CAAPL-u-4D5YKuVOsyfpDUR+PbaA3MOJmNtznS77bposQSNPjnA@mail.gmail.com>

On 02.11.23 16:43, Wei Xu wrote:
> On Wed, Nov 1, 2023 at 7:58 PM Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>>
>> On Wed, Nov 1, 2023 at 7:40 PM Wei Xu <weixugc@google.com> wrote:
>>>
>>> On Wed, Nov 1, 2023 at 4:08 PM Sourav Panda <souravpanda@google.com> wrote:
>>>>
>>>> Adds a new per-node PageMetadata field to
>>>> /sys/devices/system/node/nodeN/meminfo
>>>> and a global PageMetadata field to /proc/meminfo. This information can
>>>> be used by users to see how much memory is being used by per-page
>>>> metadata, which can vary depending on build configuration, machine
>>>> architecture, and system use.
>>>>
>>>> Per-page metadata is the amount of memory that Linux needs in order to
>>>> manage memory at the page granularity. The majority of such memory is
>>>> used by "struct page" and "page_ext" data structures. In contrast to
>>>> most other memory consumption statistics, per-page metadata might not
>>>> be included in MemTotal. For example, MemTotal does not include memblock
>>>> allocations but includes buddy allocations. While on the other hand,
>>>> per-page metadata would include both memblock and buddy allocations.
>>>
>>> I expect that the new PageMetadata field in meminfo should help break
>>> down the memory usage of a system (MemUsed, or MemTotal - MemFree),
>>> similar to the other fields in meminfo.
>>>
>>> However, given that PageMetadata includes per-page metadata allocated
>>> from not only the buddy allocator, but also the memblock allocations,
>>> and MemTotal doesn't include memory reserved by memblock allocations,
>>> I wonder how a user can actually use this new PageMetadata to break
>>> down the system memory usage.  BTW, it is not robust to assume that
>>> all memblock allocations are for per-page metadata.
>>>
>>
>> Hi Wei,
>>
>>> Here are some ideas to address this problem:
>>>
>>> - Only report the buddy allocations for per-page medata in PageMetadata, or
>>
>> Making PageMetadata not to contain all per-page memory but just some
>> is confusing, especially right after boot it would always be 0, as all
>> struct pages are all coming from memblock during boot, yet we know we
>> have allocated tons of memory for struct pages.
>>
>>> - Report per-page metadata in two separate fields in meminfo, one for
>>> buddy allocations and another for memblock allocations, or
>>
>> This is also going to be confusing for the users, it is really
>> implementation detail which allocator was used to allocate struct
>> pages, and having to trackers is not going to improve things.
>>
>>> - Change MemTotal/MemUsed to include the memblock reserved memory as well.
>>
>> I think this is the right solution for an existing bug: MemTotal
>> should really include memblock reserved memory.
> 
> Adding reserved memory to MemTotal is a cleaner approach IMO as well.
> But it changes the semantics of MemTotal, which may have compatibility
> issues.

I object.

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2023-11-02 15:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01 23:08 [PATCH v5 0/1] mm: report per-page metadata information Sourav Panda
2023-11-01 23:08 ` [PATCH v5 1/1] " Sourav Panda
2023-11-01 23:40   ` Wei Xu
2023-11-02  2:57     ` Pasha Tatashin
2023-11-02 15:43       ` Wei Xu
2023-11-02 15:47         ` David Hildenbrand [this message]
2023-11-02 15:50           ` Pasha Tatashin
2023-11-02 15:53             ` David Hildenbrand
2023-11-02 16:02               ` Pasha Tatashin
2023-11-02 16:09                 ` David Hildenbrand
2023-11-02 16:43                   ` Pasha Tatashin
2023-11-02 16:58                     ` David Hildenbrand
2023-11-02 17:11                       ` Pasha Tatashin
2023-11-02 18:06                         ` Wei Xu
2023-11-02 18:33                           ` Pasha Tatashin
2023-11-02 20:22                             ` Wei Xu
2023-11-03  1:06                               ` Pasha Tatashin
2023-11-03  4:27                                 ` Wei Xu
2023-11-03 15:18                                   ` Pasha Tatashin
2023-11-02 20:28                         ` David Hildenbrand
2023-11-02  5:42   ` Greg KH
2023-11-02 14:24     ` Pasha Tatashin
2023-11-02 14:28       ` Greg KH
2023-11-02 15:11         ` Pasha Tatashin
2023-11-02 10:19   ` Alexey Dobriyan
2023-11-17  2:42   ` kernel test robot
2023-11-02 18:13 ` [PATCH v5 0/1] " Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e99ff39-b1cf-48b8-8b6d-ba5391e00db5@redhat.com \
    --to=david@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=chenlinxuan@uniontech.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=ivan@cloudflare.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=shakeelb@google.com \
    --cc=souravpanda@google.com \
    --cc=surenb@google.com \
    --cc=tomas.mudrunka@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --cc=yang.yang29@zte.com.cn \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).