From: Thomas Gleixner <tglx@linutronix.de>
To: Shaohua Li <shli@fb.com>
Cc: John Stultz <john.stultz@linaro.org>,
lkml <linux-kernel@vger.kernel.org>,
Prarit Bhargava <prarit@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Ingo Molnar <mingo@kernel.org>,
Clark Williams <williams@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection
Date: Tue, 1 Sep 2015 20:55:38 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1509012039470.15006@nanos> (raw)
In-Reply-To: <20150901181404.GA3954400@devbig257.prn2.facebook.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4270 bytes --]
On Tue, 1 Sep 2015, Shaohua Li wrote:
> On Tue, Sep 01, 2015 at 07:13:40PM +0200, Thomas Gleixner wrote:
> > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > On Mon, Aug 31, 2015 at 11:47:52PM +0200, Thomas Gleixner wrote:
> > > > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > > > > The HPET wraps interval is 0xffffffff / 100000000 = 42.9s
> > > > > >
> > > > > > tsc interval is (0x481250b45b - 0x219e6efb50) / 2200000000 = 75s
> > > > > >
> > > > > > 32.1 + 42.9 = 75
> > > > > >
> > > > > > The example shows hpet wraps, while tsc is marked unstable
> > > > >
> > > > > Thomas & John,
> > > > > Is this data enough to prove TSC unstable issue can be triggered by HPET
> > > > > wrap? I can resend the patch with the data included.
> > > >
> > > > Well, it's enough data to prove:
> > > >
> > > > - that keeping a VM off the CPU for 75 seconds is insane.
> > >
> > > It wraps in 42.9s. 42.9s isn't a long time hard to block. I don’t think
> >
> > You think that blocking softirq execution for 42.9 seconds is normal?
> > Seems we are living in a different universe.
>
> I don't say it's normal. I say it's not hard to trigger.
So and because its not hard to trigger, we cure the symptom and do not
think about the insanity of blocking the watchdog for 42+ or 300+
seconds.
> > > it's just VM off. A softirq can hog the cpu.
> >
> > I still want to see prove of that. There is just handwaving about
> > that, but nobody has provided proper data to back that up.
>
> I showed you the TSC runs 75s, while hpet wraps. What info you think can
> prove this?
You prove nothing. You showed me the symptom, but you never showed
real data that a softirq hogs the cpu for 300+ seconds. Still you keep
claiming that.
You did neither provide a proper explanation WHY your VM test blocked
the watchdog for 75 seconds. No, you merily showed me the numbers. And
just because the numbers explain the symptom, that's no justification
WHY we should cure the symptom instead of looking at the root cause.
> > > > - that emulating the HPET with 100MHz shortens the HPET wraparound by
> > > > a factor of 7 compared to real hardware. With a realist HPET
> > > > frequency you have about 300 seconds.
> > > >
> > > > Who though that using 100MHz HPET frequency is a brilliant idea?
> > >
> > > I'm not a VM expert. My guess is the 100Mhz can reduce interrupt. It’s
> > > insane hypervisor updates HPET count in 14.3Mhz. Switching to HPET can
> > > introduce even higher overhead in virtual, because of the vmexit of
> > > iomemory access
> >
> > Sorry, that does not make any sense at all.
> >
> > - How does 100Mhz HPET frequency reduce interrupts?
> >
> > - What's insane about a lower emulated HPET frequency?
> >
> > - We all know that switching to HPET is more expensive than just
> > using TSC. That's not the question at all and completely
> > unrelated to the 100MHz HPET emulation frequency.
>
> It's meaningless to argue about HPET frequency. The code should not just
> work for 14.3Mhz HPET.
You carefully avoid to answer any of my questions, but you expect from
me to accept your wild guess argumentations?
> > I'm not pretending anything. I'm merily refusing to accept that change
> > w/o a proper explanation WHY the watchdog fails on physical hardware,
> > i.e. WHY it does not run for more than 300 seconds.
>
> It's meaningless to argue about virtual/physical machine too. Linux
> works for both virtual/physical machines.
That has nothing to do with virt vs. physical. Virtualization is meant
to provide proper hardware emulation. Does Linux work with a buggy
APIC emulation? Not at all, but you expect that it just handles an
insane HPET emulation, right?
> What about acpi_pm clocksource then? It wraps in abour 5s. It's sane
> HPET is disabled and acpi_pm is used for watchdog. Do you still think 5s
> is long?
Yes, five seconds is long. It's more than 10 billions worth of cpu
cycles on a 2GHz machine. If your desktop stalls for 5 seconds you are
probably less enthusiatic.
Again, I'm not against making the watchdog more robust, but I'm
against curing the symptoms. As long as you refuse to provide proper
explanations WHY the watchdog is blocked unduly long, this is going
nowhere.
Thanks,
tglx
next prev parent reply other threads:[~2015-09-01 18:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 20:40 [PATCH 0/9] Time items for 4.3 John Stultz
2015-08-17 20:40 ` [PATCH 1/9] timer_list: Add the base offset so remaining nsecs are accurate for non monotonic timers John Stultz
2015-08-17 21:01 ` Shuah Khan
2015-08-17 21:04 ` Shuah Khan
2015-08-17 21:05 ` John Stultz
2015-08-17 20:40 ` [PATCH 2/9] time: Fix nanosecond file time rounding in timespec_trunc() John Stultz
2015-08-17 22:14 ` Thomas Gleixner
2015-08-17 20:40 ` [PATCH 3/9] time: Always make sure wall_to_monotonic isn't positive John Stultz
2015-08-17 20:40 ` [PATCH 4/9] time: Add the common weak version of update_persistent_clock() John Stultz
2015-08-17 20:40 ` [PATCH 5/9] time: Introduce struct itimerspec64 John Stultz
2015-08-17 20:41 ` [PATCH 6/9] time: Introduce current_kernel_time64() John Stultz
2015-08-17 20:41 ` [PATCH 7/9] time: Introduce timespec64_to_jiffies()/jiffies_to_timespec64() John Stultz
2015-08-17 20:41 ` [PATCH 8/9] clocksource: Improve unstable clocksource detection John Stultz
2015-08-17 22:04 ` Thomas Gleixner
2015-08-17 22:17 ` John Stultz
2015-08-18 2:57 ` Shaohua Li
2015-08-18 3:39 ` John Stultz
2015-08-18 8:57 ` Thomas Gleixner
2015-08-18 8:38 ` Thomas Gleixner
2015-08-18 17:49 ` John Stultz
2015-08-18 19:28 ` Thomas Gleixner
2015-08-18 20:11 ` John Stultz
2015-08-18 20:18 ` Thomas Gleixner
2015-08-26 17:15 ` Shaohua Li
2015-08-31 21:12 ` Shaohua Li
2015-08-31 21:47 ` Thomas Gleixner
2015-08-31 22:39 ` Shaohua Li
2015-09-01 17:13 ` Thomas Gleixner
2015-09-01 18:14 ` Shaohua Li
2015-09-01 18:55 ` Thomas Gleixner [this message]
2015-09-01 19:35 ` Steven Rostedt
2015-09-02 6:50 ` Peter Zijlstra
2015-08-17 20:41 ` [PATCH 9/9] clocksource: Sanity check watchdog clocksource John Stultz
2015-08-17 21:24 ` Thomas Gleixner
2015-08-17 22:03 ` John Stultz
2015-08-17 22:08 ` Thomas Gleixner
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=alpine.DEB.2.11.1509012039470.15006@nanos \
--to=tglx@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=prarit@redhat.com \
--cc=richardcochran@gmail.com \
--cc=rostedt@goodmis.org \
--cc=shli@fb.com \
--cc=williams@redhat.com \
/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
all inboxes | Powered by JetHome®