All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: fweisbec@gmail.com
Cc: tglx@linutronix.de, mtosatti@redhat.com, williams@redhat.com,
	nicstange@gmail.com, linux-kernel@vger.kernel.org
Subject: [nohz_full/apic] multiple timer interrupts a second
Date: Fri, 3 Nov 2017 17:12:03 -0400	[thread overview]
Message-ID: <20171103170703.46d72a31@redhat.com> (raw)


[CC'ing lkml this time]

Hi,

I've observed that smp_apic_timer_interrupt() is sometimes called
two or more times a second on a nohz_full core which has a single
task taking 100% of the core. In one of the calls, hrtimer_interrupt()
runs tick_sched_timer(), but in others it doesn't call any handler.
Here's an example (Linus HEAD f34157878):

<...>-1831  [008]  1060.115578: funcgraph_entry:                   |  smp_apic_timer_interrupt() {
<...>-1831  [008]  1060.115578: funcgraph_entry:                   |    hrtimer_interrupt() {
<...>-1831  [008]  1060.115578: hrtimer_expire_entry: hrtimer=0xffff8edfefd12d60 function=tick_sched_timer now=1060079001980
<...>-1831  [008]  1060.115578: funcgraph_entry:        1.172 us   |      tick_sched_timer();
<...>-1831  [008]  1060.115580: funcgraph_exit:         1.757 us   |    }
<...>-1831  [008]  1060.115580: hrtimer_start:        hrtimer=0xffff8edfefd12d60 function=tick_sched_timer expires=1061079000000 softexpires=1061079000000
<...>-1831  [008]  1060.115581: funcgraph_exit:         3.026 us   |  }
<...>-1831  [008]  1061.115577: funcgraph_entry:                   |  smp_apic_timer_interrupt() {
<...>-1831  [008]  1061.115577: funcgraph_entry:        0.261 us   |    hrtimer_interrupt(); <---------- NO handler called
<...>-1831  [008]  1061.115578: funcgraph_exit:         1.349 us   |  }
<...>-1831  [008]  1061.115579: funcgraph_entry:                   |  smp_apic_timer_interrupt() {
<...>-1831  [008]  1061.115579: funcgraph_entry:                   |    hrtimer_interrupt() {
<...>-1831  [008]  1061.115579: hrtimer_expire_entry: hrtimer=0xffff8edfefd12d60 function=tick_sched_timer now=1061079001473
<...>-1831  [008]  1061.115580: funcgraph_entry:        1.413 us   |      tick_sched_timer();
<...>-1831  [008]  1061.115581: funcgraph_exit:         2.124 us   |    }
<...>-1831  [008]  1061.115582: hrtimer_start:        hrtimer=0xffff8edfefd12d60 function=tick_sched_timer expires=1062079000000 softexpires=1062079000000
<...>-1831  [008]  1061.115582: funcgraph_exit:         3.255 us   |  }

Is this expected for some reason?

I guess what's happening is that the deadline timer is firing
earlier than expected. From a few dozen to a few hundreds
nanoseconds earlier. When this happens, hrtimer_interrupt()
skips calling the hrtimer handler (since it's early) and the
apic is programmed to fire in the next microsecond.

On further research I saw that Nicolai tried to fix a very similar
problem last year:

commit 1a9e4c564ab174e53ed86def922804a5ddc63e7d
Author: Nicolai Stange <nicstange@gmail.com>
Date:   Thu Jul 14 17:22:54 2016 +0200

    x86/timers/apic: Fix imprecise timer interrupts by eliminating TSC clockevents frequency roundoff error
    
    I noticed the following bug/misbehavior on certain Intel systems: with a
    single task running on a NOHZ CPU on an Intel Haswell, I recognized
    that I did not only get the one expected local_timer APIC interrupt, but
    two per second at minimum. (!)

Maybe this issue is still present?

             reply	other threads:[~2017-11-03 21:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03 21:12 Luiz Capitulino [this message]
2017-11-04  9:14 ` [nohz_full/apic] multiple timer interrupts a second Nicolai Stange
2017-11-06 14:00   ` Luiz Capitulino

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=20171103170703.46d72a31@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nicstange@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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.