Messages in this thread | | | Date | Tue, 1 Sep 2015 11:14:17 -0700 | From | Shaohua Li <> | Subject | Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection |
| |
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.
> > 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? > > > - 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.
> > > 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.
It's meaningless to argue about virtual/physical machine too. Linux works for both virtual/physical machines.
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?
Thanks, Shaohua
| |