[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <45D23E3D.7020000@redhat.com>
Date: Tue, 13 Feb 2007 17:39:57 -0500
From: Rik van Riel <riel@...hat.com>
To: Andi Kleen <ak@....de>
CC: Arjan van de Ven <arjan@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Zachary Amsden <zach@...are.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists