From: Sheng Yang <sheng@linux.intel.com>
To: Avi Kivity <avi@redhat.com>, Qing He <qing.he@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] x86/kvm: Show guest system/user cputime in cpustat
Date: Thu, 11 Mar 2010 17:17:26 +0800 [thread overview]
Message-ID: <201003111717.26475.sheng@linux.intel.com> (raw)
In-Reply-To: <4B98A0DE.1020006@redhat.com>
On Thursday 11 March 2010 15:50:54 Avi Kivity wrote:
> On 03/11/2010 09:46 AM, Sheng Yang wrote:
> > On Thursday 11 March 2010 15:36:01 Avi Kivity wrote:
> >> On 03/11/2010 09:20 AM, Sheng Yang wrote:
> >>> Currently we can only get the cpu_stat of whole guest as one. This
> >>> patch enhanced cpu_stat with more detail, has guest_system and
> >>> guest_user cpu time statistics with a little overhead.
> >>>
> >>> Signed-off-by: Sheng Yang<sheng@linux.intel.com>
> >>> ---
> >>>
> >>> This draft patch based on KVM upstream to show the idea. I would split
> >>> it into more kernel friendly version later.
> >>>
> >>> The overhead is, the cost of get_cpl() after each exit from guest.
> >>
> >> This can be very expensive in the nested virtualization case, so I
> >> wouldn't like this to be in normal paths. I think detailed profiling
> >> like that can be left to 'perf kvm', which only has overhead if enabled
> >> at runtime.
> >
> > Yes, that's my concern too(though nested vmcs/vmcb read already too
> > expensive, they should be optimized...).
>
> Any ideas on how to do that? Perhaps use paravirt_ops to covert the
> vmread into a memory read? We store the vmwrites in the vmcs anyway.
When Qing(CCed) was working on nested VMX in the past, he found PV
vmread/vmwrite indeed works well(it would write to the virtual vmcs so vmwrite
can also benefit). Though compared to old machine(one our internal patch shows
improve more than 5%), NHM get less benefit due to the reduced vmexit cost.
--
regards
Yang, Sheng
>
> > The other concern is, perf alike mechanism would
> > bring a lot more overhead compared to this.
>
> Ordinarily users won't care if time is spent in guest kernel mode or
> guest user mode. They want to see which guest is imposing a load on a
> system. I consider a user profiling a guest from the host an advanced
> and rarer use case, so it's okay to require tools and additional
> overhead for this.
>
> >> For example you can put the code to note the cpl in a tracepoint which
> >> is enabled dynamically.
> >
> > Yanmin have already implement "perf kvm" to support this. We are just
> > arguing if a normal top-alike mechanism is necessary.
> >
> > I am also considering to make it a feature that can be disabled. But
> > seems it make things complicate and result in uncertain cpustat output.
>
> I'm not even sure that guest time was a good idea.
>
next prev parent reply other threads:[~2010-03-11 9:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-11 7:20 [PATCH] x86/kvm: Show guest system/user cputime in cpustat Sheng Yang
2010-03-11 7:36 ` Avi Kivity
2010-03-11 7:46 ` Sheng Yang
2010-03-11 7:50 ` Avi Kivity
2010-03-11 8:21 ` Zhang, Yanmin
2010-03-11 9:17 ` Sheng Yang [this message]
2010-03-12 8:53 ` Qing He
2010-03-13 8:26 ` Avi Kivity
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=201003111717.26475.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=qing.he@intel.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.