Re: [PATCH v4] x86/hpet: Reduce HPET counter read contention

[Ingo Molnar <mingo@kernel.org>]

* Waiman Long <Waiman.Long@hpe.com> wrote:

> On a large system with many CPUs, using HPET as the clock source can
> have a significant impact on the overall system performance because
> of the following reasons:
>  1) There is a single HPET counter shared by all the CPUs.
>  2) HPET counter reading is a very slow operation.
> 
> Using HPET as the default clock source may happen when, for example,
> the TSC clock calibration exceeds the allowable tolerance. Something
> the performance slowdown can be so severe that the system may crash
> because of a NMI watchdog soft lockup, for example.

>  /*
> + * Reading the HPET counter is a very slow operation. If a large number of
> + * CPUs are trying to access the HPET counter simultaneously, it can cause
> + * massive delay and slow down system performance dramatically. This may
> + * happen when HPET is the default clock source instead of TSC. For a
> + * really large system with hundreds of CPUs, the slowdown may be so
> + * severe that it may actually crash the system because of a NMI watchdog
> + * soft lockup, for example.
> + *
> + * If multiple CPUs are trying to access the HPET counter at the same time,
> + * we don't actually need to read the counter multiple times. Instead, the
> + * other CPUs can use the counter value read by the first CPU in the group.

Hm, weird, so how can this:

  static cycle_t read_hpet(struct clocksource *cs)
  {
         return (cycle_t)hpet_readl(HPET_COUNTER);
  }

... cause an actual slowdown of that magnitude? This goes straight to MMIO. So is 
the hardware so terminally broken?

How good is the TSC clocksource on the affected system? Could we simply always use 
the TSC (and not use the HPET at all as a clocksource), instead of trying to fix 
broken hardware?

Thanks,

	Ingo