All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Julien Thierry <julien.thierry@arm.com>
Cc: mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	will.deacon@arm.com, acme@kernel.org, mingo@redhat.com,
	namhyung@kernel.org, jolsa@redhat.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/9] arm_pmu: Use NMI for perf interrupt
Date: Fri, 22 Mar 2019 17:49:27 +0100	[thread overview]
Message-ID: <20190322164927.GH7905@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <1553271844-49003-1-git-send-email-julien.thierry@arm.com>

On Fri, Mar 22, 2019 at 04:23:55PM +0000, Julien Thierry wrote:
> Hi,
> 
> On arm64, perf reports that counter overflow very often (too often)
> happen in function that potentially enabled interrutps:
> 
> $ perf record -a -- sleep 60; perf report -F overhead,symbol
> [...]
> # Overhead  Symbol
> # ........  ..........................................
> #
>      6.58%  [k] _raw_spin_unlock_irq
>      6.10%  [k] _raw_spin_unlock_irqrestore
>      5.52%  [k] ___bpf_prog_run
>      4.37%  [k] el0_svc_common
>      2.58%  [k] arch_cpu_idle
>      2.39%  [k] kmem_cache_alloc
>      2.06%  [k] __seccomp_filter
>      [...]
> 
> The root issue is, if an overflow happens while executing with
> interrupts disabled, the perf event will only be handled when interrupts
> are reenabled (i.e. when the PMU interrupt is taken). The result being
> the event being reported at the interrupt enabling location rather than
> where the overflow actually happened.
> 
> Now that we have support for pseudo-NMI on arm64 with GICv3, we can use
> it to improve the profiling done using the PMU interrupt.
> 
> With these changes, on the same machine, we get:
> # Overhead  Symbol
> # ........  ..................................
> #
>      7.06%  [k] ___bpf_prog_run
>      4.08%  [k] __update_load_avg_se
>      4.02%  [k] ktime_get_ts64
>      3.77%  [k] __ll_sc_arch_atomic_add_return
>      3.71%  [k] file_ra_state_init
>      3.62%  [k] __ll_sc_arch_atomic64_sub
>      3.53%  [k] __ll_sc___cmpxchg_case_acq_32
>      [...]
> 
> _raw_spin_unlock_irq/irqrestore don't event appear anymore in the
> perf trace.

Very nice; I've little useful to say about the patches themselves, they
appear ok, but this is not code I know well. But it is good to see perf
becoming more useful on arm64.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2019-03-22 16:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 16:23 [PATCH v2 0/9] arm_pmu: Use NMI for perf interrupt Julien Thierry
2019-03-22 16:23 ` [PATCH v2 1/9] arm64: perf: avoid PMXEV* indirection Julien Thierry
2019-03-25 12:36   ` liwei (GF)
2019-03-25 13:59     ` Julien Thierry
2019-03-25 12:37   ` liwei (GF)
2019-03-25 13:59     ` Julien Thierry
2019-03-26  2:10       ` liwei (GF)
2019-03-28  9:48         ` Julien Thierry
2019-03-25 13:01   ` Marc Gonzalez
2019-07-08 11:40     ` Julien Thierry
2019-03-22 16:23 ` [PATCH v2 2/9] arm64: perf: Remove PMU locking Julien Thierry
2019-03-22 16:23 ` [PATCH v2 3/9] arm: perf: save/resore pmsel Julien Thierry
2019-03-22 16:23 ` [PATCH v2 4/9] arm: perf: Remove Remove PMU locking Julien Thierry
2019-03-22 16:24 ` [PATCH v2 5/9] perf/arm_pmu: Move PMU lock to ARMv6 events Julien Thierry
2019-03-22 16:24 ` [PATCH v2 6/9] arm64: perf: Do not call irq_work_run in NMI context Julien Thierry
2019-03-22 16:24 ` [PATCH v2 7/9] arm/arm64: kvm: pmu: Make overflow handler NMI safe Julien Thierry
2019-03-22 16:24   ` Julien Thierry
2019-03-22 16:24 ` [PATCH v2 8/9] arm_pmu: Introduce pmu_irq_ops Julien Thierry
2019-03-22 16:24 ` [PATCH v2 9/9] arm_pmu: Use NMIs for PMU Julien Thierry
2019-03-22 16:49 ` Peter Zijlstra [this message]

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=20190322164927.GH7905@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=will.deacon@arm.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.