public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Wanpeng Li <kernellwp@gmail.com>, Mike Galbraith <efault@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: tip.today - scheduler bam boom crash (cpu hotplug)
Date: Mon, 27 Feb 2017 16:59:54 +0100	[thread overview]
Message-ID: <20170227155954.GY6500@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <15367170-e1c0-8901-7e15-940d8d699c21@redhat.com>

On Mon, Feb 27, 2017 at 04:27:32PM +0100, Paolo Bonzini wrote:
> 
> 
> On 27/02/2017 14:04, Peter Zijlstra wrote:
> >>>> This results in sched clock always unstable for kvm guest since there
> >>>> is no invariant tsc cpuid bit exposed for kvm guest currently. 
> >>> What the heck is KVM_FEATURE_CLOCKSOURCE_STABLE_BIT /
> >>> PVCLOCK_TSC_STABLE_BIT about then?
> >> It checks that all the bugs in the host have been ironed out, and that
> >> the host itself supports invtsc.
> > But what does it mean if that is not so? That is, will kvm_clock_read()
> > still be stable even if !stable?
> 
> If kvmclock is !stable, nobody should have set that the sched clock to
> stable, to begin with.

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.

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().

  reply	other threads:[~2017-02-27 16:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19  7:31 tip.today - scheduler bam boom crash (cpu hotplug) Mike Galbraith
2017-01-19 10:19 ` Peter Zijlstra
2017-01-19 11:39   ` Mike Galbraith
2017-01-19 13:36   ` Peter Zijlstra
2017-01-19 16:54     ` Ingo Molnar
2017-01-19 17:20       ` Peter Zijlstra
2017-01-19 20:35     ` sched/clock: Fix hotplug issue kbuild test robot
2017-01-19 20:37     ` kbuild test robot
2017-01-20  6:36     ` [tip:sched/core] sched/clock: Fix hotplug crash tip-bot for Peter Zijlstra
2017-02-27 12:30     ` tip.today - scheduler bam boom crash (cpu hotplug) Wanpeng Li
2017-02-27 12:35       ` Paolo Bonzini
2017-02-27 12:43       ` Peter Zijlstra
2017-02-27 12:50         ` Paolo Bonzini
2017-02-27 13:04           ` Peter Zijlstra
2017-02-27 15:27             ` Paolo Bonzini
2017-02-27 15:59               ` Peter Zijlstra [this message]
2017-02-27 16:11                 ` Paolo Bonzini
2017-02-27 16:36                   ` Peter Zijlstra
2017-02-27 17:27                     ` Paolo Bonzini
2017-02-27 17:40                       ` Thomas Gleixner
2017-02-27 19:06                         ` Paolo Bonzini
2017-02-27 20:35                           ` Peter Zijlstra
2017-02-28  1:51                   ` Wanpeng Li
2017-02-28  8:08                     ` Peter Zijlstra
2017-02-28  8:11                       ` Wanpeng Li
2017-03-01 13:39                         ` Wanpeng Li
2017-03-01 14:17                           ` Peter Zijlstra
2017-02-27 13:48         ` Wanpeng Li
2017-02-27 14:05           ` Peter Zijlstra

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=20170227155954.GY6500@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=efault@gmx.de \
    --cc=kernellwp@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    /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