A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the
timer code to work for 2.6.21, which had a number of changes.
These should mostly be non-controversial and beneficial to all the
paravirt-ops work.
Zach <[email protected]>
On Mon, 2007-02-05 at 19:52 -0800, Zachary Amsden wrote:
> A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the
> timer code to work for 2.6.21, which had a number of changes.
>
> These should mostly be non-controversial and beneficial to all the
> paravirt-ops work.
Indeed, I'm expecting to push lguest this week, and this code will
effect me, so I'd like to see this in a -mm soon...
Thanks!
Rusty.
Rusty Russell wrote:
> On Mon, 2007-02-05 at 19:52 -0800, Zachary Amsden wrote:
>
>> A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the
>> timer code to work for 2.6.21, which had a number of changes.
>>
>> These should mostly be non-controversial and beneficial to all the
>> paravirt-ops work.
>>
>
> Indeed, I'm expecting to push lguest this week, and this code will
> effect me, so I'd like to see this in a -mm soon...
>
> Thanks!
> Rusty.
>
Yes, I took a look at the lguest changes today and I think these won't
generate conflicts, just make stuff easier for you ;) Course you've now
got a couple new paravirt-ops to support, but the native ones are fine
for temporary use.
Cheers,
Zach
On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote:
> Rusty Russell wrote:
> > Indeed, I'm expecting to push lguest this week, and this code will
> > effect me, so I'd like to see this in a -mm soon...
>
> Yes, I took a look at the lguest changes today and I think these won't
> generate conflicts, just make stuff easier for you ;) Course you've now
> got a couple new paravirt-ops to support, but the native ones are fine
> for temporary use.
Implementing stolen time is something I'd like to do, since it'd be a
nice self-contained example the expectations.
Patches welcome (but note that I've started a new lguest patch repo at
http://lguest.kernel.org/patches).
Thanks!
Rusty.
On Tue, 06 Feb 2007 16:11:16 +1100 Rusty Russell <[email protected]> wrote:
>
> Patches welcome (but note that I've started a new lguest patch repo at
> http://lguest.kernel.org/patches).
Presumably you mean lguest.ozlabs.org ...
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, 2007-02-06 at 16:11 +1100, Rusty Russell wrote:
> On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote:
> > Rusty Russell wrote:
> > > Indeed, I'm expecting to push lguest this week, and this code will
> > > effect me, so I'd like to see this in a -mm soon...
> >
> > Yes, I took a look at the lguest changes today and I think these won't
> > generate conflicts, just make stuff easier for you ;) Course you've now
> > got a couple new paravirt-ops to support, but the native ones are fine
> > for temporary use.
>
> Implementing stolen time is something I'd like to do, since it'd be a
> nice self-contained example the expectations.
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...
Arjan van de Ven wrote:
> On Tue, 2007-02-06 at 16:11 +1100, Rusty Russell wrote:
>
>> On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote:
>>
>>> Rusty Russell wrote:
>>>
>>>> Indeed, I'm expecting to push lguest this week, and this code will
>>>> effect me, so I'd like to see this in a -mm soon...
>>>>
>>> Yes, I took a look at the lguest changes today and I think these won't
>>> generate conflicts, just make stuff easier for you ;) Course you've now
>>> got a couple new paravirt-ops to support, but the native ones are fine
>>> for temporary use.
>>>
>> Implementing stolen time is something I'd like to do, since it'd be a
>> nice self-contained example the expectations.
>>
>
>
> 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...
>
Yes, stolen time happens in most moderns systems as a result of power
management (and you can probably count SMM cycles as stolen if only
there was a way to count them). It would be useful to report on a
laptop, for instance, how many cycles have been stolen by running off
battery or on a server because of heat issues. Having an interface for
Linux to report this seems useful. It is a covert channel, however, in
a virtualized environment, so there should be some provision in the
hypervisor to turn it off.
Zach
> 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...
If you mean it for the real time clock: Doesn't make sense then
because Linux time isn't measured in cycles
If you mean it for the scheduler: it only uses estimates for
relative fairness. As long as everybody is sloeed down in the same
way the relative fairness doesn't change.
For time accounting: the regular timer interrupt is fairly imprecise
anyawys because it samples at a low frequency. While it would be possible to
improve this it would be quite costly by slowing down interrupts and syscalls.
I'm not sure it makes that much difference here either.
I don't see the point, frankly.
-Andi
On Tue, 2007-02-06 at 13:25 +0100, 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.
I mean for showing the sysadmin that his system has spare capacity left.
right now top shows 50% in use (at say 600Mhz) while the 2.8Ghz
processor obviously isn't even nearly half loaded.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On Tue, Feb 06, 2007 at 01:45:52PM +0100, Arjan van de Ven wrote:
> On Tue, 2007-02-06 at 13:25 +0100, 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.
>
> I mean for showing the sysadmin that his system has spare capacity left.
>
> right now top shows 50% in use (at say 600Mhz) while the 2.8Ghz
> processor obviously isn't even nearly half loaded.
Not necessarily.
You have no guarantee that it will go much faster at full frequency.
e.g. if the workload is memory bound then core frequency won't affect it
much.
Also if you're using automatic frequency scaling (which probably
the far majority of users do) then if anything keeps the system
busy for some time it will scale up anyways. This means even at 50%
load you will be likely running at full speed already.
I suspect there will be that many variables that automatic adjustment
is probably not useful.
-Andi
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