From: Vlastimil Babka <vbabka@suse.cz>
To: Suren Baghdasaryan <surenb@google.com>, akpm@linux-foundation.org
Cc: 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: Mon, 17 Jun 2024 10:33:36 +0200 [thread overview]
Message-ID: <2a0ee369-12f9-401a-9179-82bd659ae201@suse.cz> (raw)
In-Reply-To: <20240614230504.3849136-1-surenb@google.com>
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.
> 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-17 8:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 23:05 Suren Baghdasaryan
2024-06-15 1:19 ` Andrew Morton
2024-06-15 3:50 ` Suren Baghdasaryan
2024-06-17 8:33 ` Vlastimil Babka [this message]
2024-06-30 19:17 ` Suren Baghdasaryan
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=2a0ee369-12f9-401a-9179-82bd659ae201@suse.cz \
--to=vbabka@suse.cz \
--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=surenb@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