* [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
@ 2024-12-26 21:16 Suren Baghdasaryan
2024-12-26 21:16 ` [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if " Suren Baghdasaryan
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-26 21:16 UTC (permalink / raw)
To: akpm
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, Suren Baghdasaryan, stable
When memory allocation profiling is disabled there is no need to update
current->alloc_tag and these manipulations add unnecessary overhead. Fix
the overhead by skipping these extra updates.
Fixes: b951aaff5035 ("mm: enable page allocation tagging")
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: stable@vger.kernel.org
---
include/linux/alloc_tag.h | 11 ++++++++---
lib/alloc_tag.c | 2 ++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
index 0bbbe537c5f9..a946e0203e6d 100644
--- a/include/linux/alloc_tag.h
+++ b/include/linux/alloc_tag.h
@@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
#define alloc_hooks_tag(_tag, _do_alloc) \
({ \
- struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \
- typeof(_do_alloc) _res = _do_alloc; \
- alloc_tag_restore(_tag, _old); \
+ typeof(_do_alloc) _res; \
+ if (mem_alloc_profiling_enabled()) { \
+ struct alloc_tag * __maybe_unused _old; \
+ _old = alloc_tag_save(_tag); \
+ _res = _do_alloc; \
+ alloc_tag_restore(_tag, _old); \
+ } else \
+ _res = _do_alloc; \
_res; \
})
diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
index 7dcebf118a3e..4c373f444eb1 100644
--- a/lib/alloc_tag.c
+++ b/lib/alloc_tag.c
@@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag);
DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
mem_alloc_profiling_key);
+EXPORT_SYMBOL(mem_alloc_profiling_key);
+
DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed);
struct alloc_tag_kernel_section kernel_tags = { NULL, 0 };
base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f
--
2.47.1.613.gc27f4b7a9f-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-26 21:16 [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled Suren Baghdasaryan
@ 2024-12-26 21:16 ` Suren Baghdasaryan
2024-12-26 23:01 ` Andrew Morton
2024-12-27 0:43 ` [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when " Kent Overstreet
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-26 21:16 UTC (permalink / raw)
To: akpm
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, Suren Baghdasaryan, stable
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@google.com>
Cc: stable@vger.kernel.org
---
lib/alloc_tag.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
index 4c373f444eb1..4e5d7af3eaa2 100644
--- a/lib/alloc_tag.c
+++ b/lib/alloc_tag.c
@@ -197,6 +197,9 @@ void pgalloc_tag_swap(struct folio *new, struct folio *old)
union codetag_ref ref_old, ref_new;
struct alloc_tag *tag_old, *tag_new;
+ if (!mem_alloc_profiling_enabled())
+ return;
+
tag_old = pgalloc_tag_get(&old->page);
if (!tag_old)
return;
--
2.47.1.613.gc27f4b7a9f-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-26 21:16 ` [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if " Suren Baghdasaryan
@ 2024-12-26 23:01 ` Andrew Morton
2024-12-26 23:07 ` Suren Baghdasaryan
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Morton @ 2024-12-26 23:01 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> Cc: stable@vger.kernel.org
Are these changes worth backporting? Some indication of how much
difference the patches make would help people understand why we're
proposing a backport.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-26 23:01 ` Andrew Morton
@ 2024-12-26 23:07 ` Suren Baghdasaryan
2024-12-27 0:23 ` Andrew Morton
0 siblings, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-26 23:07 UTC (permalink / raw)
To: Andrew Morton
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > Cc: stable@vger.kernel.org
>
> 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. The second one I couldn't really measure, so I
think it's not as important. Thanks!
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-26 23:07 ` Suren Baghdasaryan
@ 2024-12-27 0:23 ` Andrew Morton
2024-12-27 0:56 ` Suren Baghdasaryan
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Morton @ 2024-12-27 0:23 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > Cc: stable@vger.kernel.org
> >
> > 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-26 21:16 [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled Suren Baghdasaryan
2024-12-26 21:16 ` [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if " Suren Baghdasaryan
@ 2024-12-27 0:43 ` Kent Overstreet
2024-12-27 1:07 ` Suren Baghdasaryan
2024-12-27 14:17 ` kernel test robot
2024-12-27 14:39 ` kernel test robot
3 siblings, 1 reply; 18+ messages in thread
From: Kent Overstreet @ 2024-12-27 0:43 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: akpm, yuzhao, 00107082, quic_zhenhuah, linux-mm, linux-kernel,
stable
On Thu, Dec 26, 2024 at 01:16:38PM -0800, Suren Baghdasaryan wrote:
> When memory allocation profiling is disabled there is no need to update
> current->alloc_tag and these manipulations add unnecessary overhead. Fix
> the overhead by skipping these extra updates.
I did it the other way because I was concerned about the overhead of
adding a huge number of static keys. But on further thought a static key
probably isn't any bigger than an alloc tag, no?
>
> Fixes: b951aaff5035 ("mm: enable page allocation tagging")
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> Cc: stable@vger.kernel.org
> ---
> include/linux/alloc_tag.h | 11 ++++++++---
> lib/alloc_tag.c | 2 ++
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
> index 0bbbe537c5f9..a946e0203e6d 100644
> --- a/include/linux/alloc_tag.h
> +++ b/include/linux/alloc_tag.h
> @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
>
> #define alloc_hooks_tag(_tag, _do_alloc) \
> ({ \
> - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \
> - typeof(_do_alloc) _res = _do_alloc; \
> - alloc_tag_restore(_tag, _old); \
> + typeof(_do_alloc) _res; \
> + if (mem_alloc_profiling_enabled()) { \
> + struct alloc_tag * __maybe_unused _old; \
> + _old = alloc_tag_save(_tag); \
> + _res = _do_alloc; \
> + alloc_tag_restore(_tag, _old); \
> + } else \
> + _res = _do_alloc; \
> _res; \
> })
>
> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> index 7dcebf118a3e..4c373f444eb1 100644
> --- a/lib/alloc_tag.c
> +++ b/lib/alloc_tag.c
> @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag);
>
> DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
> mem_alloc_profiling_key);
> +EXPORT_SYMBOL(mem_alloc_profiling_key);
> +
> DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed);
>
> struct alloc_tag_kernel_section kernel_tags = { NULL, 0 };
>
> base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f
> --
> 2.47.1.613.gc27f4b7a9f-goog
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-27 0:23 ` Andrew Morton
@ 2024-12-27 0:56 ` Suren Baghdasaryan
2024-12-27 7:59 ` Andrew Morton
0 siblings, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 0:56 UTC (permalink / raw)
To: Andrew Morton
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > > Cc: stable@vger.kernel.org
> > >
> > > 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%.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-27 0:43 ` [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when " Kent Overstreet
@ 2024-12-27 1:07 ` Suren Baghdasaryan
2024-12-27 1:09 ` Suren Baghdasaryan
0 siblings, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 1:07 UTC (permalink / raw)
To: Kent Overstreet
Cc: akpm, yuzhao, 00107082, quic_zhenhuah, linux-mm, linux-kernel,
stable
On Thu, Dec 26, 2024 at 4:43 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Thu, Dec 26, 2024 at 01:16:38PM -0800, Suren Baghdasaryan wrote:
> > When memory allocation profiling is disabled there is no need to update
> > current->alloc_tag and these manipulations add unnecessary overhead. Fix
> > the overhead by skipping these extra updates.
>
> I did it the other way because I was concerned about the overhead of
> adding a huge number of static keys. But on further thought a static key
> probably isn't any bigger than an alloc tag, no?
Hmm but a call
>
> >
> > Fixes: b951aaff5035 ("mm: enable page allocation tagging")
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > Cc: stable@vger.kernel.org
> > ---
> > include/linux/alloc_tag.h | 11 ++++++++---
> > lib/alloc_tag.c | 2 ++
> > 2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
> > index 0bbbe537c5f9..a946e0203e6d 100644
> > --- a/include/linux/alloc_tag.h
> > +++ b/include/linux/alloc_tag.h
> > @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
> >
> > #define alloc_hooks_tag(_tag, _do_alloc) \
> > ({ \
> > - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \
> > - typeof(_do_alloc) _res = _do_alloc; \
> > - alloc_tag_restore(_tag, _old); \
> > + typeof(_do_alloc) _res; \
> > + if (mem_alloc_profiling_enabled()) { \
> > + struct alloc_tag * __maybe_unused _old; \
> > + _old = alloc_tag_save(_tag); \
> > + _res = _do_alloc; \
> > + alloc_tag_restore(_tag, _old); \
> > + } else \
> > + _res = _do_alloc; \
> > _res; \
> > })
> >
> > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> > index 7dcebf118a3e..4c373f444eb1 100644
> > --- a/lib/alloc_tag.c
> > +++ b/lib/alloc_tag.c
> > @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag);
> >
> > DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
> > mem_alloc_profiling_key);
> > +EXPORT_SYMBOL(mem_alloc_profiling_key);
> > +
> > DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed);
> >
> > struct alloc_tag_kernel_section kernel_tags = { NULL, 0 };
> >
> > base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f
> > --
> > 2.47.1.613.gc27f4b7a9f-goog
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-27 1:07 ` Suren Baghdasaryan
@ 2024-12-27 1:09 ` Suren Baghdasaryan
2024-12-27 1:46 ` Suren Baghdasaryan
0 siblings, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 1:09 UTC (permalink / raw)
To: Kent Overstreet
Cc: akpm, yuzhao, 00107082, quic_zhenhuah, linux-mm, linux-kernel,
stable
On Thu, Dec 26, 2024 at 5:07 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Dec 26, 2024 at 4:43 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Thu, Dec 26, 2024 at 01:16:38PM -0800, Suren Baghdasaryan wrote:
> > > When memory allocation profiling is disabled there is no need to update
> > > current->alloc_tag and these manipulations add unnecessary overhead. Fix
> > > the overhead by skipping these extra updates.
> >
> > I did it the other way because I was concerned about the overhead of
> > adding a huge number of static keys. But on further thought a static key
> > probably isn't any bigger than an alloc tag, no?
>
> Hmm but a call
Sorry, I pressed enter before finishing typing.
Is a call to static_branch_maybe() generate a new static key? I
thought mem_alloc_profiling_key would be used everywhere but maybe I'm
missing something?
>
> >
> > >
> > > Fixes: b951aaff5035 ("mm: enable page allocation tagging")
> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > include/linux/alloc_tag.h | 11 ++++++++---
> > > lib/alloc_tag.c | 2 ++
> > > 2 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
> > > index 0bbbe537c5f9..a946e0203e6d 100644
> > > --- a/include/linux/alloc_tag.h
> > > +++ b/include/linux/alloc_tag.h
> > > @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
> > >
> > > #define alloc_hooks_tag(_tag, _do_alloc) \
> > > ({ \
> > > - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \
> > > - typeof(_do_alloc) _res = _do_alloc; \
> > > - alloc_tag_restore(_tag, _old); \
> > > + typeof(_do_alloc) _res; \
> > > + if (mem_alloc_profiling_enabled()) { \
> > > + struct alloc_tag * __maybe_unused _old; \
> > > + _old = alloc_tag_save(_tag); \
> > > + _res = _do_alloc; \
> > > + alloc_tag_restore(_tag, _old); \
> > > + } else \
> > > + _res = _do_alloc; \
> > > _res; \
> > > })
> > >
> > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> > > index 7dcebf118a3e..4c373f444eb1 100644
> > > --- a/lib/alloc_tag.c
> > > +++ b/lib/alloc_tag.c
> > > @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag);
> > >
> > > DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
> > > mem_alloc_profiling_key);
> > > +EXPORT_SYMBOL(mem_alloc_profiling_key);
> > > +
> > > DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed);
> > >
> > > struct alloc_tag_kernel_section kernel_tags = { NULL, 0 };
> > >
> > > base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f
> > > --
> > > 2.47.1.613.gc27f4b7a9f-goog
> > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-27 1:09 ` Suren Baghdasaryan
@ 2024-12-27 1:46 ` Suren Baghdasaryan
0 siblings, 0 replies; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 1:46 UTC (permalink / raw)
To: Kent Overstreet
Cc: akpm, yuzhao, 00107082, quic_zhenhuah, linux-mm, linux-kernel,
stable
On Thu, Dec 26, 2024 at 5:09 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Dec 26, 2024 at 5:07 PM Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Thu, Dec 26, 2024 at 4:43 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Thu, Dec 26, 2024 at 01:16:38PM -0800, Suren Baghdasaryan wrote:
> > > > When memory allocation profiling is disabled there is no need to update
> > > > current->alloc_tag and these manipulations add unnecessary overhead. Fix
> > > > the overhead by skipping these extra updates.
> > >
> > > I did it the other way because I was concerned about the overhead of
> > > adding a huge number of static keys. But on further thought a static key
> > > probably isn't any bigger than an alloc tag, no?
> >
> > Hmm but a call
>
> Sorry, I pressed enter before finishing typing.
>
> Is a call to static_branch_maybe() generate a new static key? I
> thought mem_alloc_profiling_key would be used everywhere but maybe I'm
> missing something?
Or maybe you meant the NoOp/Jump generated for a static_branch ?
>
> >
> > >
> > > >
> > > > Fixes: b951aaff5035 ("mm: enable page allocation tagging")
> > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > > Cc: stable@vger.kernel.org
> > > > ---
> > > > include/linux/alloc_tag.h | 11 ++++++++---
> > > > lib/alloc_tag.c | 2 ++
> > > > 2 files changed, 10 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
> > > > index 0bbbe537c5f9..a946e0203e6d 100644
> > > > --- a/include/linux/alloc_tag.h
> > > > +++ b/include/linux/alloc_tag.h
> > > > @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
> > > >
> > > > #define alloc_hooks_tag(_tag, _do_alloc) \
> > > > ({ \
> > > > - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \
> > > > - typeof(_do_alloc) _res = _do_alloc; \
> > > > - alloc_tag_restore(_tag, _old); \
> > > > + typeof(_do_alloc) _res; \
> > > > + if (mem_alloc_profiling_enabled()) { \
> > > > + struct alloc_tag * __maybe_unused _old; \
> > > > + _old = alloc_tag_save(_tag); \
> > > > + _res = _do_alloc; \
> > > > + alloc_tag_restore(_tag, _old); \
> > > > + } else \
> > > > + _res = _do_alloc; \
> > > > _res; \
> > > > })
> > > >
> > > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> > > > index 7dcebf118a3e..4c373f444eb1 100644
> > > > --- a/lib/alloc_tag.c
> > > > +++ b/lib/alloc_tag.c
> > > > @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag);
> > > >
> > > > DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
> > > > mem_alloc_profiling_key);
> > > > +EXPORT_SYMBOL(mem_alloc_profiling_key);
> > > > +
> > > > DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed);
> > > >
> > > > struct alloc_tag_kernel_section kernel_tags = { NULL, 0 };
> > > >
> > > > base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f
> > > > --
> > > > 2.47.1.613.gc27f4b7a9f-goog
> > > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-27 0:56 ` Suren Baghdasaryan
@ 2024-12-27 7:59 ` Andrew Morton
2024-12-27 17:28 ` Suren Baghdasaryan
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Morton @ 2024-12-27 7:59 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > > > Cc: stable@vger.kernel.org
> > > >
> > > > 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??
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
@ 2024-12-27 11:47 kernel test robot
0 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2024-12-27 11:47 UTC (permalink / raw)
To: oe-kbuild; +Cc: lkp, Dan Carpenter
BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20241226211639.1357704-1-surenb@google.com>
References: <20241226211639.1357704-1-surenb@google.com>
TO: Suren Baghdasaryan <surenb@google.com>
Hi Suren,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 431614f1580a03c1a653340c55ea76bd12a9403f]
url: https://github.com/intel-lab-lkp/linux/commits/Suren-Baghdasaryan/alloc_tag-skip-pgalloc_tag_swap-if-profiling-is-disabled/20241227-051744
base: 431614f1580a03c1a653340c55ea76bd12a9403f
patch link: https://lore.kernel.org/r/20241226211639.1357704-1-surenb%40google.com
patch subject: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
:::::: branch date: 14 hours ago
:::::: commit date: 14 hours ago
config: arc-randconfig-r073-20241227 (https://download.01.org/0day-ci/archive/20241227/202412271903.leG6fSFl-lkp@intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202412271903.leG6fSFl-lkp@intel.com/
New smatch warnings:
fs/overlayfs/namei.c:658 ovl_verify_index() warn: passing zero to 'PTR_ERR'
Old smatch warnings:
fs/overlayfs/namei.c:44 ovl_check_redirect() warn: passing zero to 'PTR_ERR'
fs/overlayfs/namei.c:479 ovl_check_origin() warn: passing zero to 'PTR_ERR'
fs/overlayfs/namei.c:581 ovl_index_upper() warn: passing zero to 'ERR_CAST'
vim +/PTR_ERR +658 fs/overlayfs/namei.c
e8f9e5b780b040 Amir Goldstein 2018-01-11 598
415543d5c64fe4 Amir Goldstein 2017-06-21 599 /*
415543d5c64fe4 Amir Goldstein 2017-06-21 600 * Verify that an index entry name matches the origin file handle stored in
415543d5c64fe4 Amir Goldstein 2017-06-21 601 * OVL_XATTR_ORIGIN and that origin file handle can be decoded to lower path.
415543d5c64fe4 Amir Goldstein 2017-06-21 602 * Return 0 on match, -ESTALE on mismatch or stale origin, < 0 on error.
415543d5c64fe4 Amir Goldstein 2017-06-21 603 */
1eff1a1deec727 Amir Goldstein 2017-12-12 604 int ovl_verify_index(struct ovl_fs *ofs, struct dentry *index)
415543d5c64fe4 Amir Goldstein 2017-06-21 605 {
415543d5c64fe4 Amir Goldstein 2017-06-21 606 struct ovl_fh *fh = NULL;
415543d5c64fe4 Amir Goldstein 2017-06-21 607 size_t len;
b93436320c1e90 Chandan Rajendra 2017-07-24 608 struct ovl_path origin = { };
b93436320c1e90 Chandan Rajendra 2017-07-24 609 struct ovl_path *stack = &origin;
e8f9e5b780b040 Amir Goldstein 2018-01-11 610 struct dentry *upper = NULL;
415543d5c64fe4 Amir Goldstein 2017-06-21 611 int err;
415543d5c64fe4 Amir Goldstein 2017-06-21 612
415543d5c64fe4 Amir Goldstein 2017-06-21 613 if (!d_inode(index))
415543d5c64fe4 Amir Goldstein 2017-06-21 614 return 0;
415543d5c64fe4 Amir Goldstein 2017-06-21 615
fa0096e3bad69e Amir Goldstein 2017-10-24 616 err = -EINVAL;
cbe7fba8edfc8c Amir Goldstein 2019-11-15 617 if (index->d_name.len < sizeof(struct ovl_fb)*2)
415543d5c64fe4 Amir Goldstein 2017-06-21 618 goto fail;
415543d5c64fe4 Amir Goldstein 2017-06-21 619
415543d5c64fe4 Amir Goldstein 2017-06-21 620 err = -ENOMEM;
415543d5c64fe4 Amir Goldstein 2017-06-21 621 len = index->d_name.len / 2;
cbe7fba8edfc8c Amir Goldstein 2019-11-15 622 fh = kzalloc(len + OVL_FH_WIRE_OFFSET, GFP_KERNEL);
415543d5c64fe4 Amir Goldstein 2017-06-21 623 if (!fh)
415543d5c64fe4 Amir Goldstein 2017-06-21 624 goto fail;
415543d5c64fe4 Amir Goldstein 2017-06-21 625
415543d5c64fe4 Amir Goldstein 2017-06-21 626 err = -EINVAL;
cbe7fba8edfc8c Amir Goldstein 2019-11-15 627 if (hex2bin(fh->buf, index->d_name.name, len))
2e1a532883cf77 Amir Goldstein 2017-10-24 628 goto fail;
2e1a532883cf77 Amir Goldstein 2017-10-24 629
cbe7fba8edfc8c Amir Goldstein 2019-11-15 630 err = ovl_check_fb_len(&fh->fb, len);
2e1a532883cf77 Amir Goldstein 2017-10-24 631 if (err)
415543d5c64fe4 Amir Goldstein 2017-06-21 632 goto fail;
415543d5c64fe4 Amir Goldstein 2017-06-21 633
7db25d36d9253c Amir Goldstein 2018-01-11 634 /*
7db25d36d9253c Amir Goldstein 2018-01-11 635 * Whiteout index entries are used as an indication that an exported
7db25d36d9253c Amir Goldstein 2018-01-11 636 * overlay file handle should be treated as stale (i.e. after unlink
7db25d36d9253c Amir Goldstein 2018-01-11 637 * of the overlay inode). These entries contain no origin xattr.
7db25d36d9253c Amir Goldstein 2018-01-11 638 */
7db25d36d9253c Amir Goldstein 2018-01-11 639 if (ovl_is_whiteout(index))
7db25d36d9253c Amir Goldstein 2018-01-11 640 goto out;
7db25d36d9253c Amir Goldstein 2018-01-11 641
e8f9e5b780b040 Amir Goldstein 2018-01-11 642 /*
e8f9e5b780b040 Amir Goldstein 2018-01-11 643 * Verifying directory index entries are not stale is expensive, so
e8f9e5b780b040 Amir Goldstein 2018-01-11 644 * only verify stale dir index if NFS export is enabled.
e8f9e5b780b040 Amir Goldstein 2018-01-11 645 */
e8f9e5b780b040 Amir Goldstein 2018-01-11 646 if (d_is_dir(index) && !ofs->config.nfs_export)
e8f9e5b780b040 Amir Goldstein 2018-01-11 647 goto out;
e8f9e5b780b040 Amir Goldstein 2018-01-11 648
e8f9e5b780b040 Amir Goldstein 2018-01-11 649 /*
e8f9e5b780b040 Amir Goldstein 2018-01-11 650 * Directory index entries should have 'upper' xattr pointing to the
e8f9e5b780b040 Amir Goldstein 2018-01-11 651 * real upper dir. Non-dir index entries are hardlinks to the upper
e8f9e5b780b040 Amir Goldstein 2018-01-11 652 * real inode. For non-dir index, we can read the copy up origin xattr
e8f9e5b780b040 Amir Goldstein 2018-01-11 653 * directly from the index dentry, but for dir index we first need to
e8f9e5b780b040 Amir Goldstein 2018-01-11 654 * decode the upper directory.
e8f9e5b780b040 Amir Goldstein 2018-01-11 655 */
8ea2876577b578 Amir Goldstein 2022-10-04 656 upper = ovl_index_upper(ofs, index, false);
e8f9e5b780b040 Amir Goldstein 2018-01-11 657 if (IS_ERR_OR_NULL(upper)) {
e8f9e5b780b040 Amir Goldstein 2018-01-11 @658 err = PTR_ERR(upper);
24f0b17203691d Amir Goldstein 2018-01-11 659 /*
24f0b17203691d Amir Goldstein 2018-01-11 660 * Directory index entries with no 'upper' xattr need to be
24f0b17203691d Amir Goldstein 2018-01-11 661 * removed. When dir index entry has a stale 'upper' xattr,
24f0b17203691d Amir Goldstein 2018-01-11 662 * we assume that upper dir was removed and we treat the dir
24f0b17203691d Amir Goldstein 2018-01-11 663 * index as orphan entry that needs to be whited out.
24f0b17203691d Amir Goldstein 2018-01-11 664 */
24f0b17203691d Amir Goldstein 2018-01-11 665 if (err == -ESTALE)
24f0b17203691d Amir Goldstein 2018-01-11 666 goto orphan;
24f0b17203691d Amir Goldstein 2018-01-11 667 else if (!err)
e8f9e5b780b040 Amir Goldstein 2018-01-11 668 err = -ESTALE;
e8f9e5b780b040 Amir Goldstein 2018-01-11 669 goto fail;
e8f9e5b780b040 Amir Goldstein 2018-01-11 670 }
e8f9e5b780b040 Amir Goldstein 2018-01-11 671
610afc0bd40882 Miklos Szeredi 2020-09-02 672 err = ovl_verify_fh(ofs, upper, OVL_XATTR_ORIGIN, fh);
e8f9e5b780b040 Amir Goldstein 2018-01-11 673 dput(upper);
415543d5c64fe4 Amir Goldstein 2017-06-21 674 if (err)
415543d5c64fe4 Amir Goldstein 2017-06-21 675 goto fail;
415543d5c64fe4 Amir Goldstein 2017-06-21 676
e8f9e5b780b040 Amir Goldstein 2018-01-11 677 /* Check if non-dir index is orphan and don't warn before cleaning it */
e8f9e5b780b040 Amir Goldstein 2018-01-11 678 if (!d_is_dir(index) && d_inode(index)->i_nlink == 1) {
8a22efa15b46d5 Amir Goldstein 2018-03-09 679 err = ovl_check_origin_fh(ofs, fh, false, index, &stack);
415543d5c64fe4 Amir Goldstein 2017-06-21 680 if (err)
415543d5c64fe4 Amir Goldstein 2017-06-21 681 goto fail;
415543d5c64fe4 Amir Goldstein 2017-06-21 682
610afc0bd40882 Miklos Szeredi 2020-09-02 683 if (ovl_get_nlink(ofs, origin.dentry, index, 0) == 0)
24f0b17203691d Amir Goldstein 2018-01-11 684 goto orphan;
e8f9e5b780b040 Amir Goldstein 2018-01-11 685 }
caf70cb2ba5dff Amir Goldstein 2017-06-21 686
415543d5c64fe4 Amir Goldstein 2017-06-21 687 out:
e8f9e5b780b040 Amir Goldstein 2018-01-11 688 dput(origin.dentry);
415543d5c64fe4 Amir Goldstein 2017-06-21 689 kfree(fh);
415543d5c64fe4 Amir Goldstein 2017-06-21 690 return err;
415543d5c64fe4 Amir Goldstein 2017-06-21 691
415543d5c64fe4 Amir Goldstein 2017-06-21 692 fail:
1bd0a3aea4357e lijiazi 2019-12-16 693 pr_warn_ratelimited("failed to verify index (%pd2, ftype=%x, err=%i)\n",
61b674710cd9af Amir Goldstein 2017-07-18 694 index, d_inode(index)->i_mode & S_IFMT, err);
415543d5c64fe4 Amir Goldstein 2017-06-21 695 goto out;
24f0b17203691d Amir Goldstein 2018-01-11 696
24f0b17203691d Amir Goldstein 2018-01-11 697 orphan:
1bd0a3aea4357e lijiazi 2019-12-16 698 pr_warn_ratelimited("orphan index entry (%pd2, ftype=%x, nlink=%u)\n",
24f0b17203691d Amir Goldstein 2018-01-11 699 index, d_inode(index)->i_mode & S_IFMT,
24f0b17203691d Amir Goldstein 2018-01-11 700 d_inode(index)->i_nlink);
24f0b17203691d Amir Goldstein 2018-01-11 701 err = -ENOENT;
24f0b17203691d Amir Goldstein 2018-01-11 702 goto out;
415543d5c64fe4 Amir Goldstein 2017-06-21 703 }
415543d5c64fe4 Amir Goldstein 2017-06-21 704
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-26 21:16 [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled Suren Baghdasaryan
2024-12-26 21:16 ` [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if " Suren Baghdasaryan
2024-12-27 0:43 ` [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when " Kent Overstreet
@ 2024-12-27 14:17 ` kernel test robot
2024-12-27 14:39 ` kernel test robot
3 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2024-12-27 14:17 UTC (permalink / raw)
To: Suren Baghdasaryan; +Cc: oe-kbuild-all
Hi Suren,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 431614f1580a03c1a653340c55ea76bd12a9403f]
url: https://github.com/intel-lab-lkp/linux/commits/Suren-Baghdasaryan/alloc_tag-skip-pgalloc_tag_swap-if-profiling-is-disabled/20241227-051744
base: 431614f1580a03c1a653340c55ea76bd12a9403f
patch link: https://lore.kernel.org/r/20241226211639.1357704-1-surenb%40google.com
patch subject: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
config: x86_64-randconfig-122-20241227 (https://download.01.org/0day-ci/archive/20241227/202412272211.QSKlTw3B-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241227/202412272211.QSKlTw3B-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202412272211.QSKlTw3B-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
net/ipv6/seg6.c:252:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct in6_addr *t_old @@ got struct in6_addr [noderef] __rcu *tun_src @@
net/ipv6/seg6.c:252:15: sparse: expected struct in6_addr *t_old
net/ipv6/seg6.c:252:15: sparse: got struct in6_addr [noderef] __rcu *tun_src
>> net/ipv6/seg6.c:430:24: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct in6_addr [noderef] __rcu *tun_src @@ got void *[assigned] _res @@
net/ipv6/seg6.c:430:24: sparse: expected struct in6_addr [noderef] __rcu *tun_src
net/ipv6/seg6.c:430:24: sparse: got void *[assigned] _res
vim +430 net/ipv6/seg6.c
4f4853dc1c9c19 David Lebrun 2016-11-08 419
915d7e5e5930b4 David Lebrun 2016-11-08 420 static int __net_init seg6_net_init(struct net *net)
915d7e5e5930b4 David Lebrun 2016-11-08 421 {
915d7e5e5930b4 David Lebrun 2016-11-08 422 struct seg6_pernet_data *sdata;
915d7e5e5930b4 David Lebrun 2016-11-08 423
915d7e5e5930b4 David Lebrun 2016-11-08 424 sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
915d7e5e5930b4 David Lebrun 2016-11-08 425 if (!sdata)
915d7e5e5930b4 David Lebrun 2016-11-08 426 return -ENOMEM;
915d7e5e5930b4 David Lebrun 2016-11-08 427
915d7e5e5930b4 David Lebrun 2016-11-08 428 mutex_init(&sdata->lock);
915d7e5e5930b4 David Lebrun 2016-11-08 429
915d7e5e5930b4 David Lebrun 2016-11-08 @430 sdata->tun_src = kzalloc(sizeof(*sdata->tun_src), GFP_KERNEL);
915d7e5e5930b4 David Lebrun 2016-11-08 431 if (!sdata->tun_src) {
915d7e5e5930b4 David Lebrun 2016-11-08 432 kfree(sdata);
915d7e5e5930b4 David Lebrun 2016-11-08 433 return -ENOMEM;
915d7e5e5930b4 David Lebrun 2016-11-08 434 }
915d7e5e5930b4 David Lebrun 2016-11-08 435
915d7e5e5930b4 David Lebrun 2016-11-08 436 net->ipv6.seg6_data = sdata;
915d7e5e5930b4 David Lebrun 2016-11-08 437
f04ed7d277e842 MichelleJin 2021-09-27 438 if (seg6_hmac_net_init(net)) {
f04ed7d277e842 MichelleJin 2021-09-27 439 kfree(rcu_dereference_raw(sdata->tun_src));
23b08260481ca5 MichelleJin 2021-10-02 440 kfree(sdata);
f04ed7d277e842 MichelleJin 2021-09-27 441 return -ENOMEM;
acaea0d5a63406 Zhang Mingyu 2021-11-03 442 }
4f4853dc1c9c19 David Lebrun 2016-11-08 443
915d7e5e5930b4 David Lebrun 2016-11-08 444 return 0;
915d7e5e5930b4 David Lebrun 2016-11-08 445 }
915d7e5e5930b4 David Lebrun 2016-11-08 446
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
2024-12-26 21:16 [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled Suren Baghdasaryan
` (2 preceding siblings ...)
2024-12-27 14:17 ` kernel test robot
@ 2024-12-27 14:39 ` kernel test robot
3 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2024-12-27 14:39 UTC (permalink / raw)
To: Suren Baghdasaryan; +Cc: oe-kbuild-all
Hi Suren,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 431614f1580a03c1a653340c55ea76bd12a9403f]
url: https://github.com/intel-lab-lkp/linux/commits/Suren-Baghdasaryan/alloc_tag-skip-pgalloc_tag_swap-if-profiling-is-disabled/20241227-051744
base: 431614f1580a03c1a653340c55ea76bd12a9403f
patch link: https://lore.kernel.org/r/20241226211639.1357704-1-surenb%40google.com
patch subject: [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
config: i386-randconfig-061-20241227 (https://download.01.org/0day-ci/archive/20241227/202412272206.wWI5m9aG-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241227/202412272206.wWI5m9aG-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202412272206.wWI5m9aG-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
kernel/power/energy_model.c:168:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got struct em_perf_table * @@
kernel/power/energy_model.c:168:15: sparse: expected struct em_perf_table [noderef] __rcu *table
kernel/power/energy_model.c:168:15: sparse: got struct em_perf_table *
kernel/power/energy_model.c:169:15: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const *objp @@ got struct em_perf_table [noderef] __rcu *table @@
kernel/power/energy_model.c:169:15: sparse: expected void const *objp
kernel/power/energy_model.c:169:15: sparse: got struct em_perf_table [noderef] __rcu *table
kernel/power/energy_model.c:177:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got struct em_perf_table * @@
kernel/power/energy_model.c:177:15: sparse: expected struct em_perf_table [noderef] __rcu *table
kernel/power/energy_model.c:177:15: sparse: got struct em_perf_table *
kernel/power/energy_model.c:179:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_head [noderef] __rcu * @@
kernel/power/energy_model.c:179:19: sparse: expected struct callback_head *head
kernel/power/energy_model.c:179:19: sparse: got struct callback_head [noderef] __rcu *
kernel/power/energy_model.c:190:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@
kernel/power/energy_model.c:190:19: sparse: expected struct kref *kref
kernel/power/energy_model.c:190:19: sparse: got struct kref [noderef] __rcu *
>> kernel/power/energy_model.c:208:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got void *[assigned] _res @@
kernel/power/energy_model.c:208:15: sparse: expected struct em_perf_table [noderef] __rcu *table
kernel/power/energy_model.c:208:15: sparse: got void *[assigned] _res
kernel/power/energy_model.c:212:20: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@
kernel/power/energy_model.c:212:20: sparse: expected struct kref *kref
kernel/power/energy_model.c:212:20: sparse: got struct kref [noderef] __rcu *
kernel/power/energy_model.c:328:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@
kernel/power/energy_model.c:328:19: sparse: expected struct kref *kref
kernel/power/energy_model.c:328:19: sparse: got struct kref [noderef] __rcu *
kernel/power/energy_model.c:333:45: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:333:45: sparse: expected struct em_perf_state *table
kernel/power/energy_model.c:333:45: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:433:45: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:433:45: sparse: expected struct em_perf_state *table
kernel/power/energy_model.c:433:45: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:450:15: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const *objp @@ got struct em_perf_table [noderef] __rcu *[assigned] em_table @@
kernel/power/energy_model.c:450:15: sparse: expected void const *objp
kernel/power/energy_model.c:450:15: sparse: got struct em_perf_table [noderef] __rcu *[assigned] em_table
kernel/power/energy_model.c:634:55: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:634:55: sparse: expected struct em_perf_state *table
kernel/power/energy_model.c:634:55: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:689:16: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_state *new_ps @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:689:16: sparse: expected struct em_perf_state *new_ps
kernel/power/energy_model.c:689:16: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:707:37: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:707:37: sparse: expected struct em_perf_state *table
kernel/power/energy_model.c:707:37: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:742:38: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@
kernel/power/energy_model.c:742:38: sparse: expected struct em_perf_state *table
kernel/power/energy_model.c:742:38: sparse: got struct em_perf_state [noderef] __rcu *
kernel/power/energy_model.c:846:53: sparse: sparse: dereference of noderef expression
kernel/power/energy_model.c:855:32: sparse: sparse: dereference of noderef expression
vim +208 kernel/power/energy_model.c
ffcf9bce7af02a Lukasz Luba 2024-02-08 192
ffcf9bce7af02a Lukasz Luba 2024-02-08 193 /**
ffcf9bce7af02a Lukasz Luba 2024-02-08 194 * em_table_alloc() - Allocate a new EM table
ffcf9bce7af02a Lukasz Luba 2024-02-08 195 * @pd : EM performance domain for which this must be done
ffcf9bce7af02a Lukasz Luba 2024-02-08 196 *
ffcf9bce7af02a Lukasz Luba 2024-02-08 197 * Allocate a new EM table and initialize its kref to indicate that it
ffcf9bce7af02a Lukasz Luba 2024-02-08 198 * has a user.
ffcf9bce7af02a Lukasz Luba 2024-02-08 199 * Returns allocated table or NULL.
ffcf9bce7af02a Lukasz Luba 2024-02-08 200 */
ffcf9bce7af02a Lukasz Luba 2024-02-08 201 struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd)
ca0fc871f16f4b Lukasz Luba 2024-02-08 202 {
ca0fc871f16f4b Lukasz Luba 2024-02-08 203 struct em_perf_table __rcu *table;
ca0fc871f16f4b Lukasz Luba 2024-02-08 204 int table_size;
ca0fc871f16f4b Lukasz Luba 2024-02-08 205
ca0fc871f16f4b Lukasz Luba 2024-02-08 206 table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
ca0fc871f16f4b Lukasz Luba 2024-02-08 207
ca0fc871f16f4b Lukasz Luba 2024-02-08 @208 table = kzalloc(sizeof(*table) + table_size, GFP_KERNEL);
ffcf9bce7af02a Lukasz Luba 2024-02-08 209 if (!table)
ffcf9bce7af02a Lukasz Luba 2024-02-08 210 return NULL;
ffcf9bce7af02a Lukasz Luba 2024-02-08 211
ffcf9bce7af02a Lukasz Luba 2024-02-08 212 kref_init(&table->kref);
ffcf9bce7af02a Lukasz Luba 2024-02-08 213
ca0fc871f16f4b Lukasz Luba 2024-02-08 214 return table;
ca0fc871f16f4b Lukasz Luba 2024-02-08 215 }
ca0fc871f16f4b Lukasz Luba 2024-02-08 216
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-27 7:59 ` Andrew Morton
@ 2024-12-27 17:28 ` Suren Baghdasaryan
2024-12-27 17:32 ` Suren Baghdasaryan
2025-01-14 16:38 ` Suren Baghdasaryan
0 siblings, 2 replies; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 17:28 UTC (permalink / raw)
To: Andrew Morton
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Thu, Dec 26, 2024 at 11:59 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> > >
> > > > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > >
> > > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > > > > Cc: stable@vger.kernel.org
> > > > >
> > > > > 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.
I wish the overhead was that low :)
I ran more comprehensive testing on Pixel 6 on Big, Medium and Little cores:
Overhead before fixes Overhead after fixes
slab alloc page alloc slab alloc page alloc
Big 6.21% 5.32% 3.31% 4.93%
Medium 4.51% 5.05% 3.79% 4.39%
Little 7.62% 1.82% 6.68% 1.02%
> 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??
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-27 17:28 ` Suren Baghdasaryan
@ 2024-12-27 17:32 ` Suren Baghdasaryan
2025-01-14 16:38 ` Suren Baghdasaryan
1 sibling, 0 replies; 18+ messages in thread
From: Suren Baghdasaryan @ 2024-12-27 17:32 UTC (permalink / raw)
To: Andrew Morton
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Fri, Dec 27, 2024 at 9:28 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Dec 26, 2024 at 11:59 PM Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > > On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> > > >
> > > > > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > > >
> > > > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > > > > > Cc: stable@vger.kernel.org
> > > > > >
> > > > > > 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.
>
> I wish the overhead was that low :)
>
> I ran more comprehensive testing on Pixel 6 on Big, Medium and Little cores:
>
> Overhead before fixes Overhead after fixes
> slab alloc page alloc slab alloc page alloc
> Big 6.21% 5.32% 3.31% 4.93%
> Medium 4.51% 5.05% 3.79% 4.39%
> Little 7.62% 1.82% 6.68% 1.02%
Note, this is an allocation microbenchmark doing allocations in a
tight loop. Not a really realistic scenario and useful only to make
performance comparisons.
>
>
> > 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??
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2024-12-27 17:28 ` Suren Baghdasaryan
2024-12-27 17:32 ` Suren Baghdasaryan
@ 2025-01-14 16:38 ` Suren Baghdasaryan
2025-01-15 1:10 ` Andrew Morton
1 sibling, 1 reply; 18+ messages in thread
From: Suren Baghdasaryan @ 2025-01-14 16:38 UTC (permalink / raw)
To: Andrew Morton
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Fri, Dec 27, 2024 at 9:28 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Dec 26, 2024 at 11:59 PM Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > > On Thu, Dec 26, 2024 at 4:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> > > >
> > > > > On Thu, Dec 26, 2024 at 3:01 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > > >
> > > > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan <surenb@google.com> 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@google.com>
> > > > > > > Cc: stable@vger.kernel.org
> > > > > >
> > > > > > 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.
>
> I wish the overhead was that low :)
>
> I ran more comprehensive testing on Pixel 6 on Big, Medium and Little cores:
>
> Overhead before fixes Overhead after fixes
> slab alloc page alloc slab alloc page alloc
> Big 6.21% 5.32% 3.31% 4.93%
> Medium 4.51% 5.05% 3.79% 4.39%
> Little 7.62% 1.82% 6.68% 1.02%
Hi Andrew,
I just noticed that you added the above results to the description of
this patch in mm-unstable: 366507569511 ("alloc_tag: skip
pgalloc_tag_swap if profiling is disabled") but this improvement is
mostly caused the the other patch in this series: 80aded2b9492
("alloc_tag: avoid current->alloc_tag manipulations when profiling is
disabled"). If this is not too much trouble, could you please move it
into the description of the latter patch?
Thanks,
Suren.
>
>
> > 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??
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled
2025-01-14 16:38 ` Suren Baghdasaryan
@ 2025-01-15 1:10 ` Andrew Morton
0 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2025-01-15 1:10 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: kent.overstreet, yuzhao, 00107082, quic_zhenhuah, linux-mm,
linux-kernel, stable
On Tue, 14 Jan 2025 08:38:37 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> > > Well, a 50% reduction in a 0.0000000001% overhead ain't much.
> >
> > I wish the overhead was that low :)
> >
> > I ran more comprehensive testing on Pixel 6 on Big, Medium and Little cores:
> >
> > Overhead before fixes Overhead after fixes
> > slab alloc page alloc slab alloc page alloc
> > Big 6.21% 5.32% 3.31% 4.93%
> > Medium 4.51% 5.05% 3.79% 4.39%
> > Little 7.62% 1.82% 6.68% 1.02%
>
> Hi Andrew,
> I just noticed that you added the above results to the description of
> this patch in mm-unstable: 366507569511 ("alloc_tag: skip
> pgalloc_tag_swap if profiling is disabled") but this improvement is
> mostly caused the the other patch in this series: 80aded2b9492
> ("alloc_tag: avoid current->alloc_tag manipulations when profiling is
> disabled"). If this is not too much trouble, could you please move it
> into the description of the latter patch?
No probs, done, thanks.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2025-01-15 1:10 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-26 21:16 [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled Suren Baghdasaryan
2024-12-26 21:16 ` [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if " Suren Baghdasaryan
2024-12-26 23:01 ` Andrew Morton
2024-12-26 23:07 ` Suren Baghdasaryan
2024-12-27 0:23 ` Andrew Morton
2024-12-27 0:56 ` Suren Baghdasaryan
2024-12-27 7:59 ` Andrew Morton
2024-12-27 17:28 ` Suren Baghdasaryan
2024-12-27 17:32 ` Suren Baghdasaryan
2025-01-14 16:38 ` Suren Baghdasaryan
2025-01-15 1:10 ` Andrew Morton
2024-12-27 0:43 ` [PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when " Kent Overstreet
2024-12-27 1:07 ` Suren Baghdasaryan
2024-12-27 1:09 ` Suren Baghdasaryan
2024-12-27 1:46 ` Suren Baghdasaryan
2024-12-27 14:17 ` kernel test robot
2024-12-27 14:39 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2024-12-27 11:47 kernel test robot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.