Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection

[Shaohua Li]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/