linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jnair@caviumnetworks.com (Jayachandran C)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
Date: Mon, 1 May 2017 16:10:19 +0000	[thread overview]
Message-ID: <20170501161018.GA7112@localhost> (raw)
In-Reply-To: <20170428163823.GX13675@arm.com>

On Fri, Apr 28, 2017 at 05:38:23PM +0100, Will Deacon wrote:
> Hi guys,
> 
> On Fri, Apr 28, 2017 at 01:46:24PM +0000, Jayachandran C wrote:
> > On Thu, Apr 27, 2017 at 06:37:59PM +0100, Will Deacon wrote:
> > > > If my understanding is correct, the sysfs suggestion above is going to
> > > > add API complexity without solving the issue. Ignoring the exclude_hv if
> > > > it cannot be honored would be a better solution.
> > > 
> > > Better for HHVM, sure, but I don't think it's better in general. It means
> > > that we silently do the opposite of what the user has requested in some
> > > configurations.
> > 
> > If my understanding is correct, when is_kernel_in_hyp_mode() is true,
> > the kernel is in EL2 and there is no real hypervisor with hvc calls
> > from kernel. Ignoring the exclude_hv would be correct.
> > 
> > When kernel is in EL1, it would be correct to consider exclude_hv to
> > skip events in EL2 (reached with hvc).
> > 
> > I don't see the issue, can you please give more detail on the config
> > with unexpected behavior?
> 
> This got me thinking, so I tried to look at the history of exclude_hv. It
> turns out it was added in 0475f9ea8e2c ("perf_counters: allow users to
> count user, kernel and/or hypervisor events") for PowerPC, not x86 (where
> this doesn't seem to be supported).
> 
> Notably, it looks like it's always ignored for the x86 CPU PMU, and ignored
> on PowerPC when a hypervisor is not present. I think that backs up your
> suggestion that we should ignore it when is_kernel_in_hyp_mode() is true.
> 
> In which case, I withdraw my objection to ignoring exclude_hv when running
> in hyp mode, but please add a comment explaining the rationale!

Thanks, we will send out an updated patch with a commit message summarizing
this disucssion.

JC

      reply	other threads:[~2017-05-01 16:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 17:44 [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP Ganapatrao Kulkarni
2017-04-20  8:49 ` Mark Rutland
2017-04-20  9:26   ` Ganapatrao Kulkarni
2017-04-24 15:45     ` Will Deacon
2017-04-25  3:43       ` Ganapatrao Kulkarni
2017-04-25 16:53         ` Will Deacon
2017-04-26  6:53           ` Jayachandran C.
2017-04-26  7:22             ` Pinski, Andrew
2017-04-26 10:10               ` Will Deacon
2017-04-26 13:41                 ` Jayachandran C
2017-04-27 17:37                   ` Will Deacon
2017-04-28 13:46                     ` Jayachandran C
2017-04-28 16:38                       ` Will Deacon
2017-05-01 16:10                         ` Jayachandran C [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=20170501161018.GA7112@localhost \
    --to=jnair@caviumnetworks.com \
    --cc=linux-arm-kernel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).