From: Peter Zijlstra <peterz@infradead.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Suren Baghdasaryan <surenb@google.com>,
akpm@linux-foundation.org, kent.overstreet@linux.dev,
yuzhao@google.com, minchan@google.com, shakeel.butt@linux.dev,
souravpanda@google.com, pasha.tatashin@soleen.com,
00107082@163.com, quic_zhenhuah@quicinc.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] alloc_tag: uninline code gated by mem_alloc_profiling_key in slab allocator
Date: Tue, 28 Jan 2025 23:49:02 +0100 [thread overview]
Message-ID: <20250128224902.GA20077@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <a4919c76-73da-4974-9ca2-4c240d881df4@suse.cz>
On Sun, Jan 26, 2025 at 05:47:08PM +0100, Vlastimil Babka wrote:
> On 1/26/25 08:02, Suren Baghdasaryan wrote:
> > When a sizable code section is protected by a disabled static key, that
> > code gets into the instruction cache even though it's not executed and
> > consumes the cache, increasing cache misses. This can be remedied by
> > moving such code into a separate uninlined function. The improvement
>
> Weird, I thought the static_branch_likely/unlikely/maybe was already
> handling this by the unlikely case being a jump to a block away from the
> fast-path stream of instructions, thus making it less likely to get cached.
> AFAIU even plain likely()/unlikely() should do this, along with branch
> prediction hints.
Very much depends on the compiler :-(
sometimes unlikely just moves it to the end of the function, sometimes
it's moved to .text.unlikely.
Some compilers have label attributes:
l_yes: __attribute__((cold));
but the same compilers utterly ignore it when it's combined with
asm-goto or something -- we could never get it to work reliably.
It's been a while since I looked at this, so I'm not entirely sure what
the current version of compilers do.
next prev parent reply other threads:[~2025-01-28 22:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-26 7:02 [PATCH 1/3] mm: avoid extra mem_alloc_profiling_enabled() checks Suren Baghdasaryan
2025-01-26 7:02 ` [PATCH 2/3] alloc_tag: uninline code gated by mem_alloc_profiling_key in slab allocator Suren Baghdasaryan
2025-01-26 16:47 ` Vlastimil Babka
2025-01-27 19:38 ` Suren Baghdasaryan
2025-01-28 19:35 ` Steven Rostedt
2025-01-28 23:43 ` Suren Baghdasaryan
2025-01-29 0:03 ` Steven Rostedt
2025-01-29 9:50 ` Vlastimil Babka
2025-01-29 17:26 ` Suren Baghdasaryan
2025-01-29 2:54 ` Suren Baghdasaryan
2025-01-29 9:38 ` Vlastimil Babka
2025-01-28 22:49 ` Peter Zijlstra [this message]
2025-01-26 7:02 ` [PATCH 3/3] alloc_tag: uninline code gated by mem_alloc_profiling_key in page allocator 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=20250128224902.GA20077@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=00107082@163.com \
--cc=akpm@linux-foundation.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@google.com \
--cc=pasha.tatashin@soleen.com \
--cc=quic_zhenhuah@quicinc.com \
--cc=shakeel.butt@linux.dev \
--cc=souravpanda@google.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=yuzhao@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