mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, Jason Baron <jbaron@akamai.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Kees Cook <kees@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Lukas Bulwahn <lukas.bulwahn@redhat.com>
Subject: Re: [RFC PATCH 1/7] jump_label: expose queueing API for batched static key updates
Date: Sun, 8 Mar 2026 10:54:43 +0100	[thread overview]
Message-ID: <20260308095443.GY606826@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260306015022.1940986-2-jim.cromie@gmail.com>


First strike for not Cc'ing me on all patches in the series :/

On Thu, Mar 05, 2026 at 06:50:04PM -0700, Jim Cromie wrote:
> Currently, `HAVE_JUMP_LABEL_BATCH` provides an architecture-level
> mechanism to defer instruction synchronization (`text_poke_sync()`)
> when patching a sequence of static keys. However, this deferred
> batching capability is not exposed as a public kernel API. Subsystems
> that need to toggle a large number of static keys (e.g.,
> dynamic_debug) currently suffer from O(N) overhead due to repeated
> machine-wide synchronizations (stop_machine).
> 
> This patch introduces a public queueing API to expose this deferred
> synchronization mechanism to the rest of the kernel. This allows
> multiple static keys to be enabled/disabled by queueing their
> architecture-level updates, before applying a single machine-wide
> synchronization barrier after all instructions are modified.
> 
> The new API consists of:
> - static_key_enable_queued(key)
> - static_key_disable_queued(key)
> - static_key_apply_queued() (the global barrier/flush)
> - static_branch_enable_queued(x) / static_branch_disable_queued(x) macros
> 
> NOTES:
> 
> The '_queued' API suffix was chosen to match the underlying
> 'arch_jump_label_transform_queue' and to avoid confusion with the
> existing rate-limited 'static_key_deferred' API.
> 
> Also unify the names under the 'static_key_*' prefix, renaming
> jump_label_apply_queued to static_key_apply_queued (with a
> compatibility macro) for consistency.
> 
> A pr_debug() is added to show the poked addresses, this exposed the
> semi-random ordering coming from dynamic-debug, despite its ordered
> descriptors.
> 
> So x86/kernel/alternatives gets new code to do an insert-sort, by
> memcpy & memmove after appending.  This sorting yields a dramatic IPI
> reduction; a following patch to dynamic-debug uses the API, and
> includes the numbers.
> 

Second strike for doing *WAAAY* to many things in one patch.

> +EXPORT_SYMBOL_GPL(static_key_enable_queued);
> +EXPORT_SYMBOL_GPL(static_key_disable_queued);
> +EXPORT_SYMBOL_GPL(static_key_apply_queued);

Third strike for exposing this to modules; flipping a ton of keys is
*not* something sensible.

> +	pr_debug("incoming addr=%px, current_qlen=%d\n",
> +		 addr, text_poke_array.nr_entries);
> +

And seriously, what?!

  reply	other threads:[~2026-03-08  9:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06  1:50 [RFC PATCH 0/7] queued static-key API reduces IPIs to 134/16154 in dyndbg Jim Cromie
2026-03-06  1:50 ` [RFC PATCH 1/7] jump_label: expose queueing API for batched static key updates Jim Cromie
2026-03-08  9:54   ` Peter Zijlstra [this message]
2026-03-06  1:50 ` [RFC PATCH 2/7] virtio: use pr_debug_ratelimited to avoid flooding Jim Cromie
2026-03-06  1:50 ` [RFC PATCH 3/7] drivers/tty/serial/serial_core: ratelimit uart_wait_until_sent Jim Cromie
2026-03-06  6:32   ` Jiri Slaby
2026-03-06 14:02     ` jim.cromie
2026-03-06  1:50 ` [RFC PATCH 4/7] dyndbg: use static-key queueing API in dynamic-debug Jim Cromie
2026-03-06  1:50 ` [RFC PATCH 5/7] dyndbg: hoist static_key_apply_queued up Jim Cromie
2026-03-06  1:50 ` [RFC PATCH 6/7] lib/dynamic_debug: add negation support to queries Jim Cromie
2026-03-06  1:50 ` [RFC PATCH 7/7] dyndbg-test: test keyword !value negation Jim Cromie

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=20260308095443.GY606826@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=aliceryhl@google.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hpa@zytor.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jbaron@akamai.com \
    --cc=jgross@suse.com \
    --cc=jim.cromie@gmail.com \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@redhat.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®