public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andi Kleen <ak@muc.de>
Cc: Arjan van de Ven <arjan@infradead.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Zachary Amsden <zach@vmware.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Chris Wright <chrisw@sous-sol.org>
Subject: Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
Date: Tue, 13 Feb 2007 17:39:57 -0500	[thread overview]
Message-ID: <45D23E3D.7020000@redhat.com> (raw)
In-Reply-To: <20070206122514.GA47229@muc.de>

Andi Kleen wrote:
>> hmm stolen time could even be useful without virtualization; to a large
>> degree, if cpufreq reduces the speed of your cpu you have "stolen
>> cycles" that way... I wonder if this concept can be used for that as
>> well...

> I don't see the point, frankly.

In a virtualized environment, steal time shows the amount of
contention between guests.

If you have two guests trying to use 100% of the CPU, but they
have to share the CPU and each gets 50%, then the steal time
will be 50% on each guest.

This allows the sysadmin to see that the guests would have
been able to run faster, if only they were not fighting over
the same CPU.  Performance could have been improved by doing
live migration.

Contrast this to a client/server (or backend/middle tier)
application on one system, where both virtual machines work
together.  They can still end up getting 50% of the CPU each,
but a lot of the time they do not want the CPU simultaneously.

In that case, there will be idle time and the amount of steal
time will be way lower.

Steal time allows you to distinguish between "the CPU is not
fast enough" and "I have too many virtual machines on the CPU"
and "things are running OK".

As for steal time in a non-virtualized environment, I am not
quite sure either.  I can't think of any action the sysadmin
(or some load balancing program) could take, based on the
information...

-- 
All Rights Reversed

      parent reply	other threads:[~2007-02-13 23:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06  3:52 [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 Zachary Amsden
2007-02-06  4:27 ` Rusty Russell
2007-02-06  4:54   ` Zachary Amsden
2007-02-06  5:11     ` Rusty Russell
2007-02-06  5:24       ` Stephen Rothwell
2007-02-06  9:07       ` Arjan van de Ven
2007-02-06  9:25         ` Zachary Amsden
2007-02-06 12:25         ` Andi Kleen
2007-02-06 12:45           ` Arjan van de Ven
2007-02-06 18:16             ` Andi Kleen
2007-02-13 22:39           ` Rik van Riel [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=45D23E3D.7020000@redhat.com \
    --to=riel@redhat.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=chrisw@sous-sol.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=zach@vmware.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