* [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 @ 2007-02-06 3:52 Zachary Amsden 2007-02-06 4:27 ` Rusty Russell 0 siblings, 1 reply; 11+ messages in thread From: Zachary Amsden @ 2007-02-06 3:52 UTC (permalink / raw) To: Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Rusty Russell, Jeremy Fitzhardinge, Chris Wright, Zachary Amsden 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 <zach@vmware.com> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 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 0 siblings, 1 reply; 11+ messages in thread From: Rusty Russell @ 2007-02-06 4:27 UTC (permalink / raw) To: Zachary Amsden Cc: Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 2007-02-06 4:27 ` Rusty Russell @ 2007-02-06 4:54 ` Zachary Amsden 2007-02-06 5:11 ` Rusty Russell 0 siblings, 1 reply; 11+ messages in thread From: Zachary Amsden @ 2007-02-06 4:54 UTC (permalink / raw) To: Rusty Russell Cc: Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 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 0 siblings, 2 replies; 11+ messages in thread From: Rusty Russell @ 2007-02-06 5:11 UTC (permalink / raw) To: Zachary Amsden Cc: Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 2007-02-06 5:11 ` Rusty Russell @ 2007-02-06 5:24 ` Stephen Rothwell 2007-02-06 9:07 ` Arjan van de Ven 1 sibling, 0 replies; 11+ messages in thread From: Stephen Rothwell @ 2007-02-06 5:24 UTC (permalink / raw) To: Rusty Russell Cc: Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright On Tue, 06 Feb 2007 16:11:16 +1100 Rusty Russell <rusty@rustcorp.com.au> 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 sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 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 1 sibling, 2 replies; 11+ messages in thread From: Arjan van de Ven @ 2007-02-06 9:07 UTC (permalink / raw) To: Rusty Russell Cc: Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright 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... ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 2007-02-06 9:07 ` Arjan van de Ven @ 2007-02-06 9:25 ` Zachary Amsden 2007-02-06 12:25 ` Andi Kleen 1 sibling, 0 replies; 11+ messages in thread From: Zachary Amsden @ 2007-02-06 9:25 UTC (permalink / raw) To: Arjan van de Ven Cc: Rusty Russell, Linux Kernel Mailing List, Andrew Morton, Andi Kleen, Jeremy Fitzhardinge, Chris Wright 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 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-13 22:39 ` Rik van Riel 1 sibling, 2 replies; 11+ messages in thread From: Andi Kleen @ 2007-02-06 12:25 UTC (permalink / raw) To: Arjan van de Ven Cc: Rusty Russell, Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Jeremy Fitzhardinge, Chris Wright > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 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 1 sibling, 1 reply; 11+ messages in thread From: Arjan van de Ven @ 2007-02-06 12:45 UTC (permalink / raw) To: Andi Kleen Cc: Rusty Russell, Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Jeremy Fitzhardinge, Chris Wright 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 2007-02-06 12:45 ` Arjan van de Ven @ 2007-02-06 18:16 ` Andi Kleen 0 siblings, 0 replies; 11+ messages in thread From: Andi Kleen @ 2007-02-06 18:16 UTC (permalink / raw) To: Arjan van de Ven Cc: Rusty Russell, Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Jeremy Fitzhardinge, Chris Wright 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21 2007-02-06 12:25 ` Andi Kleen 2007-02-06 12:45 ` Arjan van de Ven @ 2007-02-13 22:39 ` Rik van Riel 1 sibling, 0 replies; 11+ messages in thread From: Rik van Riel @ 2007-02-13 22:39 UTC (permalink / raw) To: Andi Kleen Cc: Arjan van de Ven, Rusty Russell, Zachary Amsden, Linux Kernel Mailing List, Andrew Morton, Jeremy Fitzhardinge, Chris Wright 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-02-13 23:04 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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.