linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Suren Baghdasaryan <surenb@google.com>,
	lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [LSF/MM/BPF TOPIC] Memory profiling using code tagging
Date: Wed, 10 May 2023 12:28:47 -0400	[thread overview]
Message-ID: <ZFvGP211N+CuGEUT@moria.home.lan> (raw)
In-Reply-To: <115288f8-bd28-f01f-dd91-63015dcc635d@suse.cz>

On Tue, Mar 28, 2023 at 06:28:21PM +0200, Vlastimil Babka wrote:
> On 2/22/23 20:31, Suren Baghdasaryan wrote:
> > We would like to continue the discussion about code tagging use for
> > memory allocation profiling. The code tagging framework [1] and its
> > applications were posted as an RFC [2] and discussed at LPC 2022. It
> > has many applications proposed in the RFC but we would like to focus
> > on its application for memory profiling. It can be used as a
> > low-overhead solution to track memory leaks, rank memory consumers by
> > the amount of memory they use, identify memory allocation hot paths
> > and possible other use cases.
> > Kent Overstreet and I worked on simplifying the solution, minimizing
> > the overhead and implementing features requested during RFC review.
> 
> IIRC one large objection was the use of page_ext, I don't recall if you
> found another solution to that?

Hasn't been addressed yet, but we were just talking about moving the
codetag pointer from page_ext to page last night for memory overhead
reasons.

The disadvantage then is that the memory overhead doesn't go down if you
disable memory allocation profiling at boot time...

But perhaps the performance overhead is low enough now that this is not
something we expect to be doing as much?

Choices, choices...


  parent reply	other threads:[~2023-05-10 16:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 19:31 [LSF/MM/BPF TOPIC] Memory profiling using code tagging Suren Baghdasaryan
2023-03-28 16:28 ` Vlastimil Babka
2023-03-28 16:55   ` Kent Overstreet
2023-05-10 16:28   ` Kent Overstreet [this message]
2024-01-21 23:39     ` Pasha Tatashin
2024-01-21 23:56       ` Kent Overstreet
2024-01-22  1:18       ` Matthew Wilcox
2024-01-22  3:29         ` Suren Baghdasaryan
2023-05-10 16:26 ` Suren Baghdasaryan

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=ZFvGP211N+CuGEUT@moria.home.lan \
    --to=kent.overstreet@linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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).