linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	joro@8bytes.org, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrew Murray <andrew.murray@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 4/5] arm64: arm_pmu: Add support for exclude_host/exclude_guest attributes
Date: Tue, 8 Jan 2019 13:03:52 +0100	[thread overview]
Message-ID: <20190108120352.GN10769@e113682-lin.lund.arm.com> (raw)
In-Reply-To: <868szvbc64.wl-marc.zyngier@arm.com>

On Tue, Jan 08, 2019 at 11:50:59AM +0000, Marc Zyngier wrote:
> On Tue, 08 Jan 2019 11:25:13 +0000,
> Andrew Murray <andrew.murray@arm.com> wrote:
> 
> Hi Andrew,
> 
> > My only doubt about this is as follows. If, on a KVM host you run this:
> > 
> > perf stat -e cycles:H lkvm run ...
> > 
> > then on the VHE host the cycles reported represents the entire non-guest cycles
> > associated with running the guest.
> > 
> > On a !VHE, the cycles reported exclude EL2 (with or without this patch) and
> > thus you don't get a representation of all the non-guest cycles associated with
> > the guest. However without this patch you could at least still run:
> > 
> > perf stat -e cycles:H -e cycles:h lkvm run ...
> > 
> > and then add the two cycle counts together to get something comparative with
> > the VHE host.
> > 
> > If the above patch represents the desired semantics, then perhaps we must count
> > both EL1 and *EL2* for !exclude_kernel on !VHE. In fact I think we should do
> > this anyway and remove a little complexity from armv8pmu_set_event_filter.
> > Thoughts?
> 
> I'm not sure we should hide the architectural differences between VHE
> and !VHE. If you're trying to measure what is happening at in the
> hypervisor, you can't reason about it while ignoring the dual nature
> of !VHE.
> 

How do you define hypervisor here?  Is that just the code that runs at
EL2 or also parts of KVM that runs at EL1?

It remains unclear to me why you'd want to measure a subset of KVM,
which happens to run in EL2, in your host (and hypervisor-enabled)
kernel, and you are even precluded from measuring a comparable portion
of your implementation on other Arm systems (VHE).

Admittedly, I'm not at export in using perf, but I find this EL1/EL2
distinction out of place as it relates to exlude_kernel, exlude_user,
and exlude_hv.  Will we have a fourth Arm-specific flag which takes the
place of exclude_hv on PowerPC, which excludes an underlying hypervisor
when running a guest, should we ever support counting that in the
future?


Thanks,

    Christoffer

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

  reply	other threads:[~2019-01-08 12:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 10:29 [PATCH v8 0/5] arm64: Support perf event modifiers :G and :H Andrew Murray
2018-12-12 10:29 ` [PATCH v8 1/5] arm64: arm_pmu: remove unnecessary isb instruction Andrew Murray
2018-12-12 10:29 ` [PATCH v8 2/5] arm64: KVM: encapsulate kvm_cpu_context in kvm_host_data Andrew Murray
2018-12-12 10:37   ` Suzuki K Poulose
2018-12-12 12:31     ` Andrew Murray
2018-12-18 11:40   ` Christoffer Dall
2018-12-12 10:29 ` [PATCH v8 3/5] arm64: KVM: add accessors to track guest/host only counters Andrew Murray
2018-12-12 10:56   ` Suzuki K Poulose
2018-12-12 10:29 ` [PATCH v8 4/5] arm64: arm_pmu: Add support for exclude_host/exclude_guest attributes Andrew Murray
2018-12-12 10:42   ` Suzuki K Poulose
2018-12-12 10:47     ` Julien Thierry
2018-12-12 10:51       ` Suzuki K Poulose
2018-12-12 10:55   ` Suzuki K Poulose
2018-12-12 14:38     ` Andrew Murray
2018-12-18 12:02   ` Christoffer Dall
2018-12-18 13:25     ` Andrew Murray
2018-12-18 14:38       ` Christoffer Dall
2018-12-18 16:27         ` Andrew Murray
2018-12-18 18:51           ` Christoffer Dall
2018-12-18 19:19             ` Andrew Jones
2019-01-04 15:32     ` Will Deacon
2019-01-08 10:18       ` Christoffer Dall
2019-01-08 11:25         ` Andrew Murray
2019-01-08 11:50           ` Marc Zyngier
2019-01-08 12:03             ` Christoffer Dall [this message]
2019-01-08 12:12               ` Marc Zyngier
2019-01-08 12:20                 ` Christoffer Dall
2019-01-08 12:14           ` Christoffer Dall
2019-01-08 12:39             ` Andrew Murray
2018-12-12 10:29 ` [PATCH v8 5/5] arm64: KVM: Enable support for :G/:H perf event modifiers Andrew Murray
2018-12-12 10:53   ` Suzuki K Poulose
2018-12-12 14:46     ` Andrew Murray

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=20190108120352.GN10769@e113682-lin.lund.arm.com \
    --to=christoffer.dall@arm.com \
    --cc=andrew.murray@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=joro@8bytes.org \
    --cc=julien.thierry@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --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 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).