linux-kernel - Re: [PATCH 2/3] alloc_tag: uninline code gated by mem_alloc_profiling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250128224902.GA20077@noisy.programming.kicks-ass.net>
Date: Tue, 28 Jan 2025 23:49:02 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
	kent.overstreet@...ux.dev, yuzhao@...gle.com, minchan@...gle.com,
	shakeel.butt@...ux.dev, souravpanda@...gle.com,
	pasha.tatashin@...een.com, 00107082@....com,
	quic_zhenhuah@...cinc.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] alloc_tag: uninline code gated by
 mem_alloc_profiling_key in slab allocator

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.