[RFC PATCH v3 08/15] sched/clock, x86: Make __sched_clock_stable forceful

Valentin Schneider posted 15 patches 1 year, 2 months ago
There is a newer version of this series
[RFC PATCH v3 08/15] sched/clock, x86: Make __sched_clock_stable forceful
Posted by Valentin Schneider 1 year, 2 months ago
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(-)

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;
 
 /*
-- 
2.43.0
Re: [RFC PATCH v3 08/15] sched/clock, x86: Make __sched_clock_stable forceful
Posted by Peter Zijlstra 1 year, 2 months ago
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?
Re: [RFC PATCH v3 08/15] sched/clock, x86: Make __sched_clock_stable forceful
Posted by Valentin Schneider 1 year, 2 months ago
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.
Re: [RFC PATCH v3 08/15] sched/clock, x86: Make __sched_clock_stable forceful
Posted by Peter Zijlstra 1 year, 2 months ago
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.