linux-kernel - Re: [GIT PULL] Introduce try_alloc

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: <CAADnVQKyLod8gNz-RR2=bs=vJJWiGhZ5GB4t68aNPNWndptr0w@mail.gmail.com>
Date: Sun, 30 Mar 2025 17:33:27 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: bpf <bpf@...r.kernel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, 
	Vlastimil Babka <vbabka@...e.cz>, Sebastian Sewior <bigeasy@...utronix.de>, 
	Steven Rostedt <rostedt@...dmis.org>, Michal Hocko <mhocko@...e.com>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, linux-mm <linux-mm@...ck.org>, 
	LKML <linux-kernel@...r.kernel.org>, Johannes Weiner <hannes@...xchg.org>
Subject: Re: [GIT PULL] Introduce try_alloc_pages for 6.15

On Sun, Mar 30, 2025 at 3:08 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, 30 Mar 2025 at 14:30, Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > But to avoid being finger pointed, I'll switch to checking alloc_flags
> > first. It does seem a better trade off to avoid cache bouncing because
> > of 2nd cmpxchg. Though when I wrote it this way I convinced myself and
> > others that it's faster to do trylock first to avoid branch misprediction.
>
> Yes, the really hot paths (ie core locking) do the "trylock -> read
> spinning" for that reason. Then for the normal case, _only_ the
> trylock is in the path, and that's the best of both worlds.
>
> And in practice, the "do two compare-and-exchange" operations actually
> does work fine, because the cacheline will generally be sticky enough
> that you don't actually get many extra cachline bouncing.

Right, but I also realized that in the contended case there is
an unnecessary irq save/restore pair.
Posted the fix:
https://lore.kernel.org/bpf/20250331002809.94758-1-alexei.starovoitov@gmail.com/

maybe apply directly?

I'll send the renaming fix once we converge on a good name.