From: Avi Kivity <avi@redhat.com>
To: Davidlohr Bueso <dave@gnu.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
lkml <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: VMX: add tracepoint for vpids
Date: Tue, 13 Mar 2012 12:10:21 +0200 [thread overview]
Message-ID: <4F5F1D0D.8080408@redhat.com> (raw)
In-Reply-To: <1331636285.12394.4.camel@offworld>
On 03/13/2012 12:58 PM, Davidlohr Bueso wrote:
> On Mon, 2012-03-12 at 12:34 +0200, Avi Kivity wrote:
> > On 03/12/2012 01:29 PM, Davidlohr Bueso wrote:
> > > On Mon, 2012-03-12 at 10:22 +0200, Avi Kivity wrote:
> > > > On 03/11/2012 05:57 PM, Davidlohr Bueso wrote:
> > > > > From: Davidlohr Bueso <dave@gnu.org>
> > > > >
> > > > > Add a new tracepoint for vpid allocation and freeing associated to all vCPUs.
> > > > >
> > > >
> > > > Why?
> > > >
> > >
> > > We have been using this tracepoint for some time now to help debug vpids
> > > and simulating tagged TLB behavior and performance. This gets to be non
> > > trivial when working with large amounts of guests and vCPUs.
> >
> > I don't follow. Can you give an example of when this tracepoint would
> > be useful?
> >
>
> For example when running lots of guests with many different hardware
> configurations (ept on/off, vpid on/off) I trace what vcpu has or
> doesn't have a corresponding vpid associated. Perhaps this is more
> useful for experimental things than actual KVM development.
So it seems. Tracepoints should be useful for production deployments,
not development.
--
error compiling committee.c: too many arguments to function
prev parent reply other threads:[~2012-03-13 10:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-11 15:57 [PATCH] KVM: VMX: add tracepoint for vpids Davidlohr Bueso
2012-03-12 8:22 ` Avi Kivity
2012-03-12 11:29 ` Davidlohr Bueso
2012-03-12 10:34 ` Avi Kivity
2012-03-13 10:58 ` Davidlohr Bueso
2012-03-13 10:10 ` Avi Kivity [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=4F5F1D0D.8080408@redhat.com \
--to=avi@redhat.com \
--cc=dave@gnu.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@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.