[Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

[Peter Zijlstra]

On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> 
> 
> On 12/04/17 17:32, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
> > 
> > > > > So, why is this only affecting the Core 2 Duo?
> > > > 
> > > > Core2 doesn't have a usable TSC and would revert to the slow path. I'll
> > > > have another look at that patch.
> > > > 
> > > 
> > > So, by default, it is using the hpet clock source. FYI, I tried the only
> > > other available clock source (acpi_pm) and got the same result.
> > 
> > So because HPET is unbearably slow we've cobbled together something that
> > takes the HPET (or rather get-time-of-day CLOCK_MONOTONIC) value at tick
> > time and uses TSC to add per-cpu increments to that. Using windowing to
> > keep the TSC maddness at bay.
> > 
> > The patch in question affects the windowing.. clearly something went
> > amiss.
> > 
> 
> Good to know. Is there a way to disable this behaviour, as a workaround for
> our CI system until a proper fix lands? We already pushed locally the revert
> for this patch, but that may affect other platforms which do not exhibit the
> problem.

No, the only thing you can do is revert for now.