| Message ID | 20241119153502.41361-9-vschneid@redhat.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
| Series | context_tracking,x86: Defer some IPIs until a user->kernel transition | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
On Tue, Nov 19, 2024 at 04:34:55PM +0100, Valentin Schneider wrote: > Later commits will cause objtool to warn about non __ro_after_init static > keys being used in .noinstr sections in order to safely defer instruction > patching IPIs targeted at NOHZ_FULL CPUs. > > __sched_clock_stable is used in .noinstr code, and can be modified at > runtime (e.g. KVM module loading). Suppressing the text_poke_sync() IPI has Wait, what !? loading KVM causes the TSC to be marked unstable?
On 20/11/24 15:59, Peter Zijlstra wrote: > On Tue, Nov 19, 2024 at 04:34:55PM +0100, Valentin Schneider wrote: >> Later commits will cause objtool to warn about non __ro_after_init static >> keys being used in .noinstr sections in order to safely defer instruction >> patching IPIs targeted at NOHZ_FULL CPUs. >> >> __sched_clock_stable is used in .noinstr code, and can be modified at >> runtime (e.g. KVM module loading). Suppressing the text_poke_sync() IPI has > > Wait, what !? loading KVM causes the TSC to be marked unstable? Ah, maybe not, I saw the below but that's actually the x86 specific stuff and IIUC can only be builtin: kvm_init_platform() `\ kvmclock_init() `\ kvm_sched_clock_init() `\ clear_sched_clock_stable() There is however this: kvm_arch_vcpu_load() `\ mark_tsc_unstable() So plugging a VCPU might do that.
On Wed, Nov 20, 2024 at 05:34:32PM +0100, Valentin Schneider wrote: > On 20/11/24 15:59, Peter Zijlstra wrote: > > On Tue, Nov 19, 2024 at 04:34:55PM +0100, Valentin Schneider wrote: > >> Later commits will cause objtool to warn about non __ro_after_init static > >> keys being used in .noinstr sections in order to safely defer instruction > >> patching IPIs targeted at NOHZ_FULL CPUs. > >> > >> __sched_clock_stable is used in .noinstr code, and can be modified at > >> runtime (e.g. KVM module loading). Suppressing the text_poke_sync() IPI has > > > > Wait, what !? loading KVM causes the TSC to be marked unstable? > > There is however this: > > kvm_arch_vcpu_load() > `\ > mark_tsc_unstable() > > So plugging a VCPU might do that. Right, but that only happens if it observes the TSC doing dodgy, so that's deserved and shouldn't happen on hardware from this decade, and possibly the one before that.
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c index 200e5568b9894..dc94b3717f5ce 100644 --- a/kernel/sched/clock.c +++ b/kernel/sched/clock.c @@ -76,7 +76,7 @@ static DEFINE_STATIC_KEY_FALSE_RO(sched_clock_running); * Similarly we start with __sched_clock_stable_early, thereby assuming we * will become stable, such that there's only a single 1 -> 0 transition. */ -static DEFINE_STATIC_KEY_FALSE(__sched_clock_stable); +static DEFINE_STATIC_KEY_FALSE_FORCE(__sched_clock_stable); static int __sched_clock_stable_early = 1; /*
Later commits will cause objtool to warn about non __ro_after_init static keys being used in .noinstr sections in order to safely defer instruction patching IPIs targeted at NOHZ_FULL CPUs. __sched_clock_stable is used in .noinstr code, and can be modified at runtime (e.g. KVM module loading). Suppressing the text_poke_sync() IPI has little benefits for this key, as NOHZ_FULL is incompatible with an unstable TSC anyway. Mark it as forceful to let the kernel know to always send the text_poke_sync() IPI for it, and to let objtool know not to warn about it. Signed-off-by: Valentin Schneider <vschneid@redhat.com> --- kernel/sched/clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)