Re: [RFC PATCH V2 11/11] x86: tsc: avoid system instability in hibernation

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> Hey Peter,
> 
> On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2020 at 11:45:26PM +0000, Anchal Agarwal wrote:
> > > From: Eduardo Valentin <eduval@amazon.com>
> > > 
> > > System instability are seen during resume from hibernation when system
> > > is under heavy CPU load. This is due to the lack of update of sched
> > > clock data, and the scheduler would then think that heavy CPU hog
> > > tasks need more time in CPU, causing the system to freeze
> > > during the unfreezing of tasks. For example, threaded irqs,
> > > and kernel processes servicing network interface may be delayed
> > > for several tens of seconds, causing the system to be unreachable.
> > 
> > > The fix for this situation is to mark the sched clock as unstable
> > > as early as possible in the resume path, leaving it unstable
> > > for the duration of the resume process. This will force the
> > > scheduler to attempt to align the sched clock across CPUs using
> > > the delta with time of day, updating sched clock data. In a post
> > > hibernation event, we can then mark the sched clock as stable
> > > again, avoiding unnecessary syncs with time of day on systems
> > > in which TSC is reliable.
> > 
> > This makes no frigging sense what so bloody ever. If the clock is
> > stable, we don't care about sched_clock_data. When it is stable you get
> > a linear function of the TSC without complicated bits on.
> > 
> > When it is unstable, only then do we care about the sched_clock_data.
> > 
> 
> Yeah, maybe what is not clear here is that we covering for situation
> where clock stability changes over time, e.g. at regular boot clock is
> stable, hibernation happens, then restore happens in a non-stable clock.

Still confused, who marks the thing unstable? The patch seems to suggest
you do yourself, but it is not at all clear why.

If TSC really is unstable, then it needs to remain unstable. If the TSC
really is stable then there is no point in marking is unstable.

Either way something is off, and you're not telling me what.

> > > Reviewed-by: Erik Quanstrom <quanstro@amazon.com>
> > > Reviewed-by: Frank van der Linden <fllinden@amazon.com>
> > > Reviewed-by: Balbir Singh <sblbir@amazon.com>
> > > Reviewed-by: Munehisa Kamata <kamatam@amazon.com>
> > > Tested-by: Anchal Agarwal <anchalag@amazon.com>
> > > Signed-off-by: Eduardo Valentin <eduval@amazon.com>
> > > ---
> > 
> > NAK, the code very much relies on never getting marked stable again
> > after it gets set to unstable.
> > 
> 
> Well actually, at the PM_POST_HIBERNATION, we do the check and set stable if
> known to be stable.
> 
> The issue only really happens during the restoration path under scheduling pressure,
> which takes forever to finish, as described in the commit.
> 
> Do you see a better solution for this issue?

I still have no clue what your actual problem is. You say scheduling
goes wobbly because sched_clock_data is stale, but when stable that
doesn't matter.

So what is the actual problem?