Received-SPF: pass (google.com: domain of linux-kernel+bounces-67912-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240214225741.403783-1-souravpanda@google.com>
 <20240214225741.403783-2-souravpanda@google.com> <20240215161441.c8a2350a61f6929c0dbe9e7b@linux-foundation.org>
 <CAJuCfpHF=yxV9+=pUo+5DwSjvF=r2y7A9_8LHsUGUSoP7EUNXA@mail.gmail.com>
In-Reply-To: <CAJuCfpHF=yxV9+=pUo+5DwSjvF=r2y7A9_8LHsUGUSoP7EUNXA@mail.gmail.com>
From: Pasha Tatashin <pasha.tatashin@soleen.com>
Date: Thu, 15 Feb 2024 19:51:37 -0500
Message-ID: <CA+CK2bDH9E_nHs4FVYxuOUcddL_asOTTXHJd1FuVmGfEGNeZXw@mail.gmail.com>
Subject: Re: [PATCH v8 1/1] mm: report per-page metadata information
To: Suren Baghdasaryan <surenb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Sourav Panda <souravpanda@google.com>, corbet@lwn.net, 
	gregkh@linuxfoundation.org, rafael@kernel.org, mike.kravetz@oracle.com, 
	muchun.song@linux.dev, rppt@kernel.org, david@redhat.com, 
	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, 
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, 
	weixugc@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 15, 2024 at 7:40=E2=80=AFPM Suren Baghdasaryan <surenb@google.c=
om> wrote:
>
> On Thu, Feb 15, 2024 at 4:14=E2=80=AFPM Andrew Morton <akpm@linux-foundat=
ion.org> wrote:
> >
> > On Wed, 14 Feb 2024 14:57:40 -0800 Sourav Panda <souravpanda@google.com=
> wrote:
> >
> > > Adds two new per-node fields, namely nr_memmap and nr_memmap_boot,
> > > to /sys/devices/system/node/nodeN/vmstat and a global Memmap 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.
> >
> > Would this information be available by the proposed memory
> > allocation profiling?
>
> Well, not without jumping through the hoops. You would need to find
> the places in the source code where all this matadata is allocated and
> find the appropriate records inside /proc/allocinfo file.

Another difference is that memory allocation profiling does not report
memblock allocated memory, this patch reports the amount of per-page
metadata allocated by the memblock allocator in addition to various
paths that are used to allocate per-page metdata after the buddy
allocator is initialized. Also, the memory profiling has page_ext
overhead, so it is not practical to unconditionally enable it
throughout the fleet.

Pasha