All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Joerg Roedel <joro@8bytes.org>
Cc: Avi Kivity <avi@redhat.com>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	KVM General <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Zachary Amsden <zamsden@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	ming.m.lin@intel.com, "Zhang,
	Yanmin" <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: KVM PMU virtualization
Date: Mon, 1 Mar 2010 09:44:50 +0100	[thread overview]
Message-ID: <20100301084450.GF19395@elte.hu> (raw)
In-Reply-To: <20100228161142.GA19879@8bytes.org>


* Joerg Roedel <joro@8bytes.org> wrote:

> On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote:
> >  - A paravirt event driver is more compatible and more transparent in the long 
> >    run: it allows hardware upgrade and upgraded PMU functionality (for Linux) 
> >    without having to upgrade the guest OS. Via that a guest OS could even be
> >    live-migrated to a different PMU, without noticing anything about it.
> > 
> >    In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS 
> >    always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state 
> >    cannot be live-migrated. (save/restore doesnt help)
> 
> I agree with your arguments, having this soft-pmu for the guest has some 
> advantages over raw pmu access. It has a lot of advantages if the guest 
> migrated between hosts with different hardware.
> 
> But I still think we should have both, a soft-pmu and a pmu-emulation (which 
> is a more accurate term than 'raw guest pmu access') that looks to the guest 
> as a real hardware pmu would look like.  On a linux host that is dedicated 
> to executing virtual kvm machines there is little point in sharing the pmu 
> between guest and host because the host will probably never use it.

There's a world of a difference between "will not use in certain usecases" and 
"cannot use at all because we've designed it so". By doing the latter we 
guarantee that sane shared usage of the PMU will never occur - which is bad.

Really, similar arguments have been made in the past about different domains 
of system usage: "one profiling session per system is more than enough, who 
needs transparent, per user profilers", etc. Such restrictions have been 
broken through again and again.

Think about it: this whole Linux thing is about 'sharing' resources. That 
concet really works and permeates everything we do in the kernel. Yes, it's 
somewhat hard for the PMU but we've done it on the host side via perf events 
and we really dont want to look back ...

My experience is that once the right profiling/tracing tools are there, people 
will use them in every which way. The bigger a box is, the more likely shared 
usage will occur - just statistically. Which coincides with KVM's "the bigger 
the box, the better for virtualization" general mantra.

	Ingo

  parent reply	other threads:[~2010-03-01  8:45 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-25 15:04 KVM PMU virtualization Jes Sorensen
2010-02-25 15:44 ` Jan Kiszka
2010-02-25 16:26   ` Ingo Molnar
2010-02-26  2:52     ` Zhang, Yanmin
2010-02-26  8:45       ` Ingo Molnar
2010-02-26 11:03     ` Jes Sorensen
2010-02-25 17:34 ` Joerg Roedel
2010-02-26  2:55   ` Zhang, Yanmin
2010-02-26  8:51     ` Joerg Roedel
2010-02-26  9:17       ` Ingo Molnar
2010-02-26 10:42         ` Joerg Roedel
2010-02-26 10:56           ` Ingo Molnar
2010-03-02  7:09         ` Zhang, Yanmin
2010-03-02  9:36           ` Ingo Molnar
2010-03-03  3:32             ` Zhang, Yanmin
2010-03-03  9:27               ` Zhang, Yanmin
2010-03-03 10:13                 ` Peter Zijlstra
2010-03-04  0:52                   ` Zhang, Yanmin
2010-03-03 10:15                 ` Peter Zijlstra
2010-03-04  1:00                   ` Zhang, Yanmin
2010-03-10  9:29                     ` Zhang, Yanmin
2010-03-02  9:57           ` Peter Zijlstra
2010-02-26  8:42   ` Ingo Molnar
2010-02-26  9:46     ` Avi Kivity
2010-02-26 10:39       ` Joerg Roedel
2010-02-26 10:46         ` Ingo Molnar
2010-02-26 10:51           ` Avi Kivity
2010-02-26 11:06           ` Joerg Roedel
2010-02-26 11:18             ` Jes Sorensen
2010-02-26 11:24               ` Ingo Molnar
2010-02-26 11:25                 ` Jes Sorensen
2010-02-26 11:20             ` Ingo Molnar
2010-02-26 10:44       ` Ingo Molnar
2010-02-26 11:16         ` Avi Kivity
2010-02-26 11:26           ` Ingo Molnar
2010-02-26 11:47             ` Avi Kivity
2010-02-26 11:23         ` Jes Sorensen
2010-02-26 11:42           ` Ingo Molnar
2010-02-26 11:51             ` Avi Kivity
2010-02-26 12:07               ` Ingo Molnar
2010-02-26 12:20                 ` Avi Kivity
2010-02-26 12:38                   ` Ingo Molnar
2010-02-26 13:04                     ` Avi Kivity
2010-02-26 13:13                       ` Jes Sorensen
2010-02-26 13:27                         ` Ingo Molnar
2010-02-26 13:33                           ` Avi Kivity
2010-02-26 14:07                           ` Jes Sorensen
2010-02-26 14:11                             ` Avi Kivity
2010-02-26 13:18                       ` Ingo Molnar
2010-02-26 13:34                         ` Jes Sorensen
2010-02-26 12:56                   ` Jes Sorensen
2010-02-26 13:31                   ` Ingo Molnar
2010-02-26 13:37                     ` Jes Sorensen
2010-02-26 13:55                       ` Avi Kivity
2010-02-26 14:27                         ` Peter Zijlstra
2010-02-26 14:54                           ` Avi Kivity
2010-02-26 15:08                             ` Peter Zijlstra
2010-02-26 15:11                               ` Avi Kivity
2010-02-26 15:18                                 ` Peter Zijlstra
2010-02-26 15:55                                 ` Peter Zijlstra
2010-02-26 16:06                                   ` Avi Kivity
2010-03-01 19:03                                   ` Zachary Amsden
2010-03-01 18:54                       ` Zachary Amsden
2010-02-26 13:40                     ` Avi Kivity
2010-02-26 14:01                       ` Ingo Molnar
2010-02-26 14:22                         ` Avi Kivity
2010-02-26 14:37                           ` Ingo Molnar
2010-02-26 16:03                             ` Avi Kivity
2010-02-26 16:07                               ` Avi Kivity
2010-02-26 13:28               ` Peter Zijlstra
2010-02-26 13:44                 ` Avi Kivity
2010-02-26 13:51                 ` Jes Sorensen
2010-02-26 14:42                   ` Peter Zijlstra
2010-03-08 18:14                     ` Avi Kivity
2010-02-26 12:49             ` Jes Sorensen
2010-02-26 13:06               ` Ingo Molnar
2010-02-26 13:30                 ` Avi Kivity
2010-02-26 13:32                   ` Jes Sorensen
2010-02-26 13:44                   ` Ingo Molnar
2010-02-26 13:53                     ` Avi Kivity
2010-02-26 14:12                       ` Ingo Molnar
2010-02-26 14:53                         ` Avi Kivity
2010-02-26 15:14                           ` Peter Zijlstra
2010-02-28 16:34                             ` Joerg Roedel
2010-02-28 16:31                         ` Joerg Roedel
2010-02-28 16:11                     ` Joerg Roedel
2010-03-01  8:39                       ` Ingo Molnar
2010-03-01  8:58                         ` Joerg Roedel
2010-03-01  9:04                           ` Ingo Molnar
2010-03-01  8:44                       ` Ingo Molnar [this message]
2010-03-01 11:11                         ` Joerg Roedel
2010-03-01 17:17                           ` Peter Zijlstra
2010-03-01 18:36                             ` Joerg Roedel
2010-03-08 10:15                             ` Avi Kivity
2010-02-26 14:49                   ` Peter Zijlstra
2010-02-26 14:50                   ` Peter Zijlstra
2010-02-26 13:31                 ` Jes Sorensen
2010-03-01 17:22             ` Zachary Amsden
2010-02-26 11:01   ` Jes Sorensen

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=20100301084450.GF19395@elte.hu \
    --to=mingo@elte.hu \
    --cc=Jes.Sorensen@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=arjan@infradead.org \
    --cc=avi@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=gleb@redhat.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=yanmin_zhang@linux.intel.com \
    --cc=zamsden@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.