From: Suren Baghdasaryan <surenb@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev,
pasha.tatashin@soleen.com, souravpanda@google.com,
keescook@chromium.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: handle profiling for fake memory allocations during compaction
Date: Sun, 30 Jun 2024 12:17:32 -0700 [thread overview]
Message-ID: <CAJuCfpE+ae8VSZFEsy0rp19dCFHgT4fOR3MnSWORYa3ORJOjqw@mail.gmail.com> (raw)
In-Reply-To: <2a0ee369-12f9-401a-9179-82bd659ae201@suse.cz>
On Mon, Jun 17, 2024 at 1:33 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 6/15/24 1:05 AM, Suren Baghdasaryan wrote:
> > During compaction isolated free pages are marked allocated so that they
> > can be split and/or freed. For that, post_alloc_hook() is used inside
> > split_map_pages() and release_free_list(). split_map_pages() marks free
> > pages allocated, splits the pages and then lets alloc_contig_range_noprof()
> > free those pages. release_free_list() marks free pages and immediately
>
> Well in case of split_map_pages() only some of them end up freed, but most
> should be used as migration targets. But we move the tags from the source
> page during migration and unaccount the ones from the target (i.e. from the
> instrumented post_alloc_hook() after this patch), right? So it should be ok,
> just the description here is incomplete.
Sorry for the delay with replying, Vlastimil.
Yes, you are correct. Some of these pages are not immediately freed
but migrated and during migration the destination gets charged for
them. As a result these new counters should still read 0 most of the
time except for some intermediate states.
I can amend the description if this is considered important.
Thanks,
Suren.
>
> > frees them. This usage of post_alloc_hook() affect memory allocation
> > profiling because these functions might not be called from an instrumented
> > allocator, therefore current->alloc_tag is NULL and when debugging is
> > enabled (CONFIG_MEM_ALLOC_PROFILING_DEBUG=y) that causes warnings.
> > To avoid that, wrap such post_alloc_hook() calls into an instrumented
> > function which acts as an allocator which will be charged for these
> > fake allocations. Note that these allocations are very short lived until
> > they are freed, therefore the associated counters should usually read 0.
> >
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
>
> > ---
> > mm/compaction.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index e731d45befc7..739b1bf3d637 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -79,6 +79,13 @@ static inline bool is_via_compact_memory(int order) { return false; }
> > #define COMPACTION_HPAGE_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > #endif
> >
> > +static struct page *mark_allocated_noprof(struct page *page, unsigned int order, gfp_t gfp_flags)
> > +{
> > + post_alloc_hook(page, order, __GFP_MOVABLE);
> > + return page;
> > +}
> > +#define mark_allocated(...) alloc_hooks(mark_allocated_noprof(__VA_ARGS__))
> > +
> > static void split_map_pages(struct list_head *freepages)
> > {
> > unsigned int i, order;
> > @@ -93,7 +100,7 @@ static void split_map_pages(struct list_head *freepages)
> >
> > nr_pages = 1 << order;
> >
> > - post_alloc_hook(page, order, __GFP_MOVABLE);
> > + mark_allocated(page, order, __GFP_MOVABLE);
> > if (order)
> > split_page(page, order);
> >
> > @@ -122,7 +129,7 @@ static unsigned long release_free_list(struct list_head *freepages)
> > * Convert free pages into post allocation pages, so
> > * that we can free them via __free_page.
> > */
> > - post_alloc_hook(page, order, __GFP_MOVABLE);
> > + mark_allocated(page, order, __GFP_MOVABLE);
> > __free_pages(page, order);
> > if (pfn > high_pfn)
> > high_pfn = pfn;
> >
> > base-commit: c286c21ff94252f778515b21b6bebe749454a852
>
next prev parent reply other threads:[~2024-06-30 19:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 23:05 [PATCH 1/1] mm: handle profiling for fake memory allocations during compaction Suren Baghdasaryan
2024-06-15 1:19 ` Andrew Morton
2024-06-15 3:50 ` Suren Baghdasaryan
2024-06-17 8:33 ` Vlastimil Babka
2024-06-30 19:17 ` Suren Baghdasaryan [this message]
2024-07-02 9:32 ` Vlastimil Babka
2024-07-02 15:17 ` 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=CAJuCfpE+ae8VSZFEsy0rp19dCFHgT4fOR3MnSWORYa3ORJOjqw@mail.gmail.com \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=souravpanda@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).