Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 19 Apr 2018 13:05:39 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Imre Deak <imre.deak@intel.com>
cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: Early timeouts due to inaccurate jiffies during system
 suspend/resume
In-Reply-To: <20180419013200.wxkzqfdacfsijci5@ideak-desk.fi.intel.com>
Message-ID: <alpine.DEB.2.21.1804191256200.1563@nanos.tec.linutronix.de>
References: <20180419013200.wxkzqfdacfsijci5@ideak-desk.fi.intel.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 19 Apr 2018, Imre Deak wrote:
> Hi,
> 
> while checking bug [1], I noticed that jiffies based timing loops like
> 
> 	expire = jiffies + timeout + 1;
> 	while (!time_after(jiffies, expire))
> 		do_something;
> 
> can last shorter than expected (that is less than timeout).

Yes, that can happen when the timer interrupt is delayed long enough for
whatever reason. If you need accurate timing then you need to use
ktime_get().

> After some ftracing it seems like jiffies gets stale due to a missed
> LAPIC timer interrupt after the interrupt is armed in
> lapic_next_deadline() and before jiffies is sampled at 2. above.
> Eventually the interrupt does get delivered, at which point jiffies gets
> updated via tick_do_update_jiffies64() with a >1 ticks increment.
> Between lapic_next_deadline() and the - late - delivery of the interrupt
> the CPU on which the interrupt is armed doesn't go idle.

That's odd. I have no real explanation for that.

Thanks,

	tglx