From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753897AbbIAROR (ORCPT ); Tue, 1 Sep 2015 13:14:17 -0400 Received: from www.linutronix.de ([62.245.132.108]:55091 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753276AbbIAROQ (ORCPT ); Tue, 1 Sep 2015 13:14:16 -0400 Date: Tue, 1 Sep 2015 19:13:40 +0200 (CEST) From: Thomas Gleixner To: Shaohua Li cc: John Stultz , lkml , Prarit Bhargava , Richard Cochran , Daniel Lezcano , Ingo Molnar , Clark Williams , Steven Rostedt , Peter Zijlstra Subject: Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection In-Reply-To: <20150831223931.GA1586538@devbig257.prn2.facebook.com> Message-ID: References: <20150826171533.GA2189998@devbig257.prn2.facebook.com> <20150831211233.GA1413758@devbig257.prn2.facebook.com> <20150831223931.GA1586538@devbig257.prn2.facebook.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-930378812-1441127622=:15006" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-930378812-1441127622=:15006 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT 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. > 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. > > - 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. > > So we should add crappy heuristics to the watchdog just to workaround > > virt insanities? I'm not convinced. > > This is a real issue which could impact performance seriously. Though > the data is collected in vm, we do see the issue happens in physical > machines too. And what's the exact reason for this on physical machines? Some magic softirq hog again for which you cannot provide proof? > The watchdog clock source shows restriction here apparently, it > deserves an improvement if we can do. The restriction in a sane environment is 300 seconds. And the only fallout on physical hardware which we have seen so far is on preempt-RT where the softirq can actually be blocked by RT hogs, but that's a completely different issue and has nothing to do with the situation in mainline. > I'm happy to hear from you if there is better solution, but we > shouldn't pretend there is no issue here. 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. Thanks, tglx --8323329-930378812-1441127622=:15006--