Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1588795

Re: tip.today - scheduler bam boom crash (cpu hotplug)

From Paolo Bonzini <pbonzini@redhat.com>
Newsgroups linux.kernel
Subject Re: tip.today - scheduler bam boom crash (cpu hotplug)
Date 2017-02-27 17:30 +0100
Message-ID <tfwls-86h-15@gated-at.bofh.it> (permalink)
References (4 earlier) <tfsUx-5CV-1@gated-at.bofh.it> <tft4e-5G3-1@gated-at.bofh.it> <tfvz5-7vd-45@gated-at.bofh.it> <tfvz5-7vd-43@gated-at.bofh.it> <tfwls-86h-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 27/02/2017 16:59, Peter Zijlstra wrote:
> OK, so if !KVM_FEATURE_CLOCKSOURCE_STABLE_BIT nothing is stable, but if
> it is set, TSC might still not be stable, but kvm_clock_read() is.
> 
>> However, if kvmclock is stable, we know that the sched clock is stable.
> Right, so the problem is that we only ever want to allow marking
> unstable -- once its found unstable, for whatever reason, we should
> never allow going stable. The corollary of this proposition is that we
> must start out assuming it will become stable. And to avoid actually
> using unstable TSC we do a 3 state bringup:
> 
>  1) sched_clock_running = 0, __stable_early = 1, __stable = 0
>  2) sched_clock_running = 1 (__stable is effective, iow, we run unstable)
>  3) sched_clock_running = 2 (__stable <- __stable_early)
> 
> 2) happens 'early' but is 'safe'.
> 3) happens 'late', after we've brought up SMP and probed TSC
> 
> Between there, we should have detected the most common TSC wreckage and
> made sure to not then switch to 'stable' at 3.
> 
> Now the problem appears to be that we assume sched_clock will use RDTSC
> (native_sched_clock) while sched_clock is a paravirt op.
> 
> Now, I've not yet figured out the ordering between when we set
> pv_time_ops.sched_clock and when we do the 'normal' TSC init stuff.

I think the ordering is fine:

- pv_time_ops.sched_clock is set here:

	start_kernel (init/main.c line 509)
	  setup_arch
	    kvmclock_init
	      kvm_sched_clock_init

- TSC can be declared unstable only after this:

	start_kernel (init/main.c line 628)
	  late_time_init
	    tsc_init

So by the time the tsc_cs_mark_unstable or mark_tsc_unstable can call
clear_sched_clock_stable, pv_time_ops.sched_clock has been set.

> But it appears to me, we should not be calling
> clear_sched_clock_stable() on TSC bits when we don't end up using
> native_sched_clock().

Yes, this makes sense.

Paolo

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: tip.today - scheduler bam boom crash (cpu hotplug) Wanpeng Li <kernellwp@gmail.com> - 2017-02-27 13:40 +0100
  Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-27 13:50 +0100
    Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 14:00 +0100
      Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 16:40 +0100
        Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 17:30 +0100
          Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-27 17:40 +0100
            Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 18:30 +0100
              Re: tip.today - scheduler bam boom crash (cpu hotplug) Thomas Gleixner <tglx@linutronix.de> - 2017-02-27 19:10 +0100
                Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 20:10 +0100
                Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-28 00:00 +0100
          Re: tip.today - scheduler bam boom crash (cpu hotplug) Wanpeng Li <kernellwp@gmail.com> - 2017-02-28 03:00 +0100
            Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-28 09:10 +0100
              Re: tip.today - scheduler bam boom crash (cpu hotplug) Wanpeng Li <kernellwp@gmail.com> - 2017-02-28 09:20 +0100
        Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-27 17:50 +0100
      Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-27 23:50 +0100
    Re: tip.today - scheduler bam boom crash (cpu hotplug) Wanpeng Li <kernellwp@gmail.com> - 2017-02-27 15:00 +0100
      Re: tip.today - scheduler bam boom crash (cpu hotplug) Peter Zijlstra <peterz@infradead.org> - 2017-02-27 15:50 +0100
  Re: tip.today - scheduler bam boom crash (cpu hotplug) Paolo Bonzini <pbonzini@redhat.com> - 2017-02-27 16:10 +0100

csiph-web