On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> >
> > > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> > > >
> > > > > When memory allocation profiling is disabled, there is no need to swap
> > > > > allocation tags during migration. Skip it to avoid unnecessary overhead.
> > > > >
> > > > > Fixes: e0a955bf7f61 ("mm/codetag: add pgalloc_tag_copy()")
> > > > > Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > >
> > > > Are these changes worth backporting? Some indication of how much
> > > > difference the patches make would help people understand why we're
> > > > proposing a backport.
> > >
> > > The first patch ("alloc_tag: avoid current->alloc_tag manipulations
> > > when profiling is disabled") I think is worth backporting. It
> > > eliminates about half of the regression for slab allocations when
> > > profiling is disabled.
> >
> > um, what regression? The changelog makes no mention of this. Please
> > send along a suitable Reported-by: and Closes: and a summary of the
> > benefits so that people can actually see what this patch does, and why.
>
> Sorry, I should have used "overhead" instead of "regression".
> When one sets CONFIG_MEM_ALLOC_PROFILING=y, the code gets instrumented
> and even if profiling is turned off, it still has a small performance
> cost minimized by the use of mem_alloc_profiling_key static key. I
> found a couple of places which were not protected with
> mem_alloc_profiling_key, which means that even when profiling is
> turned off, the code is still executed. Once I added these checks, the
> overhead of the mode when memory profiling is enabled but turned off
> went down by about 50%.
Well, a 50% reduction in a 0.0000000001% overhead ain't much. But I
added the final sentence to the changelog.
It still doesn't tell us the very simple thing which we're all eager to
know: how much faster did the kernel get??
