All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Thu, 19 Apr 2018 13:05:39 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1804191256200.1563@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180419013200.wxkzqfdacfsijci5@ideak-desk.fi.intel.com>

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

  reply	other threads:[~2018-04-19 11:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19  1:32 Early timeouts due to inaccurate jiffies during system suspend/resume Imre Deak
2018-04-19 11:05 ` Thomas Gleixner [this message]
2018-04-23 17:01   ` Imre Deak
2018-04-24 14:07     ` Imre Deak
2018-04-24 14:21       ` Ville Syrjälä
2018-04-26 21:40       ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1804191256200.1563@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=imre.deak@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.