public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@fb.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	John Stultz <john.stultz@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH v3] Fix: clocksource watchdog marks TSC unstable on guest VM
Date: Wed, 9 Sep 2015 08:43:05 -0700	[thread overview]
Message-ID: <20150909154249.GA3563967@devbig257.prn2.facebook.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1509091148090.3854@nanos>

On Wed, Sep 09, 2015 at 11:51:43AM +0200, Thomas Gleixner wrote:
> On Tue, 8 Sep 2015, Shaohua Li wrote:
> > On Tue, Sep 08, 2015 at 05:08:03PM +0200, Thomas Gleixner wrote:
> > > For non paravirt kernels which can read the TSC directly, we'd need a
> > > way to transport that information. A simple mechanism would be to
> > > query an emulated MSR from the watchdog which tells the guest the
> > > state of affairs on the host side. That would be a sensible and
> > > minimal invasive change on both host and guests.
> > 
> > This will require every hypervisor supports the MSR, so not a solution
> > we can expect immediately.
> 
> I know.
>  
> > I'm wondering why we can't just make the watchdog better to detect this
> > watchdog wrap.
> 
> Again, I'm not opposed to make it better. I'm just trying to prevent
> making the watchdog a total mess for no reason.
> 
> > It can happen in physical machine as I said before, but I
> > can't find a simple way to trigger it, so it's not very convincing. But
> > the watchdog doesn't work for specific environment (for exmaple, a bogus
> > hardware doesn't responsond for some time) for sure, we shouldn't assume
> > the world is perfect.
> 
> Sigh. If the damned hardware blocks long enough to wreckage the
> watchdog then we have more serious problems than that.

There is difference. If hardware blocks, we can choose reset the
hardware or we can just ignore it if it's a serial console or netconsole
(these are what happend in our side) for example.  These impact the
system very little.  But if HPET is the clocksource, the performance of
the system will be quite poor and makes the whole system useless. There
is no method to reset the clocksource to TSC. If there is a reset
mechanism, it's fine too.
 
> Can you please stop this handwaving and provide some proper proof for
> your arguments? I'm really tired of this.

I'm sorry I can't provide a simple way to trigger it in real hardware,
but it's not hard to trigger this issue in kvm. Just make your host busy
and keep rebooting your virtual machine, you will find it.

Thanks,
Shaohua

      reply	other threads:[~2015-09-09 15:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 14:19 [RFC PATCH v3] Fix: clocksource watchdog marks TSC unstable on guest VM Mathieu Desnoyers
2015-09-08 15:08 ` Thomas Gleixner
2015-09-09  1:03   ` Shaohua Li
2015-09-09  9:51     ` Thomas Gleixner
2015-09-09 15:43       ` Shaohua Li [this message]

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=20150909154249.GA3563967@devbig257.prn2.facebook.com \
    --to=shli@fb.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=gleb@kernel.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --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