linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: perf with precise attribute kills all KVM based VMs
Date: Sun, 15 Jul 2012 20:19:55 -0600	[thread overview]
Message-ID: <50037A4B.4050900@gmail.com> (raw)
In-Reply-To: <20120712160634.GI7298@redhat.com>

On 7/12/12 10:06 AM, Gleb Natapov wrote:
>> I started with cycles:pp; should not really matter - they all need
>> to work without blowing up VMs (cycles:p, cycles:pH, cycles:pG,
>> cycles:pp, cycles:ppH, cycles:ppG).
> cycles:ppG and cycles:pG should be illegal. Peter's patch takes care of
> this. Others should set exclude guest and have to work without blowing
> up VMs.

I was only testing your patch; I'll add Peter's going forward.

---8<---

>> perf kvm --guestmount=/tmp/guest-mount record -fo /tmp/perf.data -a
>> -v -e cycles:pH -- sleep 60
> Do not run perf kvm. It does not set exclude_guest and :p and :pp is not
> compatible with guest profiling and should be disallowed. Again Peter's
> patch takes care of this.

Well, perf-kvm needs to work too - and yes you can set exclude_guest 
with it (doesn't make sense to use perf-kvm with exclude_guest, but then 
VMs should not die because of it). If someone adds -e <hardware 
event>:p{p} it needs to be handled cleanly. The G and H event modifiers 
can be used explicitly to exclude host or guest and that case too needs 
to be handled properly from whatever the context is.

Peter's patch handles kernel side checks requiring exclude_guest if the 
pebs is to be used. A user running perf-kvm, perf-record and perf-top 
deserves something better than a confusing 'not supported error' which 
includes a message suggesting perf events is not enabled. I have some 
local patches for record and top to cover this.

>
> Run perf top -e cycles:pH or similar.
>
>>
>> Note the :pH this time.
> I am not sure what perf kvm does with :pH modifier, but H modifier does
> not make sense with perf kvm and should be reported as an error by perf tool.

perf-kvm passes everything from record on to the builtin record command. 
So, 'perf kvm record -e cycles:pH' effectively becomes 'perf record -e 
cycles:pH' with 2 global flags modified (perf_guest set and perf_host 
unset). There is nothing invalid about the perf-kvm command.

---8<---

>> My server has 16 cpus and the VM has only 2 vcpus; with the -a I
>> would expect some host sampling. Note: in the above case :pp resets
>> the exclude-host modifier set by the perf-kvm part, so hosts samples
>> are not excluded. See parse_events_modifier().
> Isn't this a bug? Why anything at all resets exclude-host set by
> perf-kvm?

Arguably yes and arguably no. As with any linux command later arguments 
can unset/reset earlier ones. In this case -e <event>:<modifier> comes 
after the perf-kvm --guest --host settings. I can whip up a patch for 
perf {record,top} to spit out a debug message if perf_{guest,host} are 
not consistent with excl_{guest,host} if that's wanted.

Don't forget -- perf-kvm has the --host flag to enable host side 
monitoring and --no-guest can be used to disable guest side monitoring.

David

  parent reply	other threads:[~2012-07-16  2:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 14:12 perf with precise attribute kills all KVM based VMs David Ahern
2012-07-09 14:19 ` Gleb Natapov
2012-07-09 14:24   ` Peter Zijlstra
2012-07-09 14:36     ` Gleb Natapov
2012-07-09 14:39     ` Avi Kivity
2012-07-09 14:47       ` David Ahern
2012-07-09 14:49         ` Peter Zijlstra
2012-07-09 14:51           ` Avi Kivity
2012-07-09 14:54             ` Gleb Natapov
2012-07-09 14:57               ` Gleb Natapov
2012-07-09 14:59             ` Peter Zijlstra
2012-07-10 23:38               ` David Ahern
2012-07-11  7:10                 ` Gleb Natapov
2012-07-11  9:49                   ` Peter Zijlstra
2012-07-11  9:53                     ` Gleb Natapov
2012-07-11 13:34                       ` David Ahern
2012-07-12  4:11                       ` David Ahern
2012-07-12  4:29                         ` Gleb Natapov
2012-07-12 15:20                           ` David Ahern
2012-07-12 16:06                             ` Gleb Natapov
2012-07-12 16:13                               ` Gleb Natapov
2012-07-12 16:58                                 ` Peter Zijlstra
2012-07-16  1:51                                 ` David Ahern
2012-07-15  8:07                               ` Avi Kivity
2012-07-15 13:00                                 ` David Ahern
2012-07-15 13:03                                   ` Avi Kivity
2012-07-16  1:52                                     ` David Ahern
2012-07-16  2:19                               ` David Ahern [this message]
2012-07-20 23:34                   ` David Ahern
2012-07-22  9:52                     ` Avi Kivity
2012-07-09 14:52           ` David Ahern
2012-07-09 14:58             ` David Ahern
2012-07-09 15:18               ` David Ahern
2012-07-09 14:47       ` Peter Zijlstra
2012-07-20 23:35         ` David Ahern

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=50037A4B.4050900@gmail.com \
    --to=dsahern@gmail.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.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 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).