From: Ingo Molnar <mingo@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Masami Hiramatsu <mhiramat@kernel.org>,
x86@kernel.org, bpf@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>,
Greg Thelen <gthelen@google.com>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] x86/alternatives: remove false sharing in poke_int3_handler()
Date: Sun, 23 Mar 2025 22:38:15 +0100 [thread overview]
Message-ID: <Z-B_R737uM31m6_K@gmail.com> (raw)
In-Reply-To: <20250323072511.2353342-1-edumazet@google.com>
* Eric Dumazet <edumazet@google.com> wrote:
> eBPF programs can be run 20,000,000+ times per second on busy servers.
>
> Whenever /proc/sys/kernel/bpf_stats_enabled is turned off,
> hundreds of calls sites are patched from text_poke_bp_batch()
> and we see a critical loss of performance due to false sharing
> on bp_desc.refs lasting up to three seconds.
> @@ -2413,8 +2415,12 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
> /*
> * Remove and wait for refs to be zero.
> */
> - if (!atomic_dec_and_test(&bp_desc.refs))
> - atomic_cond_read_acquire(&bp_desc.refs, !VAL);
> + for_each_possible_cpu(i) {
> + atomic_t *refs = per_cpu_ptr(&bp_refs, i);
> +
> + if (!atomic_dec_and_test(refs))
> + atomic_cond_read_acquire(refs, !VAL);
> + }
So your patch changes text_poke_bp_batch() to busy-spin-wait for
bp_refs to go to zero on all 480 CPUs.
Your measurement is using /proc/sys/kernel/bpf_stats_enabled on a
single CPU, right?
What's the adversarial workload here? Spamming bpf_stats_enabled on all
CPUs in parallel? Or mixing it with some other text_poke_bp_batch()
user if bpf_stats_enabled serializes access?
Does anything undesirable happen in that case?
Thanks,
Ingo
next prev parent reply other threads:[~2025-03-23 21:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-23 7:25 [PATCH] x86/alternatives: remove false sharing in poke_int3_handler() Eric Dumazet
2025-03-23 21:38 ` Ingo Molnar [this message]
2025-03-24 3:59 ` Eric Dumazet
2025-03-24 7:16 ` Ingo Molnar
2025-03-24 7:47 ` Eric Dumazet
2025-03-24 7:53 ` Eric Dumazet
2025-03-24 8:04 ` Ingo Molnar
2025-03-24 11:33 ` Peter Zijlstra
2025-03-25 8:41 ` Ingo Molnar
2025-03-25 10:30 ` Peter Zijlstra
2025-03-25 11:26 ` Ingo Molnar
2025-03-25 12:31 ` Peter Zijlstra
2025-03-27 20:56 ` Ingo Molnar
2025-03-25 11:36 ` [tip: x86/alternatives] x86/alternatives: Document the text_poke_bp_batch() synchronization rules a bit more tip-bot2 for Peter Zijlstra
2025-03-24 8:02 ` [PATCH] x86/alternatives: remove false sharing in poke_int3_handler() Ingo Molnar
2025-03-24 8:20 ` Eric Dumazet
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=Z-B_R737uM31m6_K@gmail.com \
--to=mingo@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=edumazet@google.com \
--cc=eranian@google.com \
--cc=eric.dumazet@gmail.com \
--cc=gthelen@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 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.