linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Wei Xu <weixugc@google.com>,
	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 21:28:27 +0100	[thread overview]
Message-ID: <efbcce1f-e5ad-4e82-a684-96c6d609a097@redhat.com> (raw)
In-Reply-To: <CA+CK2bCNRJXm2kEjsN=5a_M8twai4TJX3vpd72uOHFLGaDLg4g@mail.gmail.com>

On 02.11.23 18:11, Pasha Tatashin wrote:
>>> Wei, noticed that all other fields in /proc/meminfo are part of
>>> MemTotal, but this new field may be not (depending where struct pages
>>
>> I could have sworn that I pointed that out in a previous version and
>> requested to document that special case in the patch description. :)
> 
> Sounds, good we will document that parts of per-page may not be part
> of MemTotal.
> 
>>> are allocated), so what would be the best way to export page metadata
>>> without redefining MemTotal? Keep the new field in /proc/meminfo but
>>> be ok that it is not part of MemTotal or do two counters? If we do two
>>> counters, we will still need to keep one that is a buddy allocator in
>>> /proc/meminfo and the other one somewhere outside?
>>
>> IMHO, we should just leave MemTotal alone ("memory managed by the buddy
>> that could actually mostly get freed up and reused -- although that's
>> not completely true") and have a new counter that includes any system
>> memory (MemSystem? but as we learned, as separate files), including most
>> memblock allocations/reservations as well (metadata, early pagetables,
>> initrd, kernel, ...).
>>
>> The you would actually know how much memory the system is using
>> (exclusing things like crashmem, mem=, ...).
>>
>> That part is tricky, though -- I recall there are memblock reservations
>> that are similar to the crashkernel -- which is why the current state is
>> to account memory when it's handed to the buddy under MemTotal -- which
>> is straight forward and simply.
> 
> It may be simplified if we define MemSystem as all the usable memory
> provided by firmware to Linux kernel.
> For BIOS it would be the "usable" ranges in the original e820 memory
> list before it's been modified by the kernel based on the parameters.

There are some cases to consider, like "mem=", crashkernel, and some 
more odd things (I believe there are some on ppc at least for hw tracing 
buffers).

All information should be in the memblock allocator, maybe we just have 
to find some ways to better enlighten it what an allocation is (e.g., 
memmap), and what some other reason to exclude memory is (crash kernel, 
mem=, ACPI tables, odd memory holes, ...).

-- 
Cheers,

David / dhildenb


  parent reply	other threads:[~2023-11-02 20:28 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
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 [this message]
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=efbcce1f-e5ad-4e82-a684-96c6d609a097@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).