On Wed, 2011-01-26 at 13:13 +0200, Avi Kivity wrote:
On 01/24/2011 08:06 PM, Glauber Costa wrote:
As a proof of concept to KVM - Kernel Virtual Memory, this patch
implements wallclock grabbing on top of it. At first, it may seem
as a waste of work to just redo it, since it is working well
On Wed, 2011-01-26 at 17:14 +0200, Avi Kivity wrote:
On 01/26/2011 02:14 PM, Glauber Costa wrote:
On Wed, 2011-01-26 at 13:12 +0200, Avi Kivity wrote:
On 01/24/2011 08:06 PM, Glauber Costa wrote:
KVM, which stands for KVM Virtual Memory (I wanted to call it KVM
Virtual Mojito
On Wed, 2011-01-26 at 17:12 +0200, Avi Kivity wrote:
On 01/26/2011 02:13 PM, Glauber Costa wrote:
- it doesn't lend itself will to live migration. Extra state must be
maintained in the hypervisor.
Yes, but can be queried at any time as well. I don't do it in this
patch
On Wed, 2011-01-26 at 10:57 +0100, Peter Zijlstra wrote:
On Tue, 2011-01-25 at 19:27 -0200, Glauber Costa wrote:
On Tue, 2011-01-25 at 22:07 +0100, Peter Zijlstra wrote:
On Tue, 2011-01-25 at 18:47 -0200, Glauber Costa wrote:
On Tue, 2011-01-25 at 21:13 +0100, Peter Zijlstra wrote
On Wed, 2011-01-26 at 17:17 +0200, Avi Kivity wrote:
On 01/26/2011 02:20 PM, Glauber Costa wrote:
On Wed, 2011-01-26 at 13:13 +0200, Avi Kivity wrote:
On 01/24/2011 08:06 PM, Glauber Costa wrote:
As a proof of concept to KVM - Kernel Virtual Memory, this patch
implements
On Wed, 2011-01-26 at 17:46 +0100, Peter Zijlstra wrote:
On Wed, 2011-01-26 at 13:43 -0200, Glauber Costa wrote:
yes, but once this delta is subtracted from rq-clock_task, this value is
not
used to dictate power, unless I am mistaken.
power is adjusted according to scale_rt_power
On Mon, 2011-01-24 at 20:51 +0100, Peter Zijlstra wrote:
On Mon, 2011-01-24 at 16:51 -0200, Glauber Costa wrote:
I would really much rather see you change update_rq_clock_task() and
subtract your ns resolution steal time from our wall-time,
update_rq_clock_task() already updates
On Tue, 2011-01-25 at 21:13 +0100, Peter Zijlstra wrote:
On Tue, 2011-01-25 at 18:02 -0200, Glauber Costa wrote:
I fail to see how does clock_task influence cpu power.
If we also have to touch clock_task for better accounting of other
stuff, it is a separate story.
But for cpu_power, I
On Tue, 2011-01-25 at 22:07 +0100, Peter Zijlstra wrote:
On Tue, 2011-01-25 at 18:47 -0200, Glauber Costa wrote:
On Tue, 2011-01-25 at 21:13 +0100, Peter Zijlstra wrote:
On Tue, 2011-01-25 at 18:02 -0200, Glauber Costa wrote:
I fail to see how does clock_task influence cpu power
backports to people who wants to backport the kernel part but not the
hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_para.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86
to facilitate backports to people who wants to
backport
the kernel part but not the hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff
backports to people who wants to backport the kernel part but not the
hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/kernel/kvmclock.c | 31 ++-
1 files changed, 22 insertions(+), 9
Register steal time within KVM. Everytime we sample the steal time
information, we update a local variable that tells what was the
last time read. We then account the difference.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge
keeping it separate from
the headers to facilitate backports to people who wants to backport the kernel
part but not the hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
CC
. If this is, or if this will not, be accounted
as steal time for the guest, is a guest's decision.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
CC: Peter Zijlstra pet...@infradead.org
CC: Avi Kivity a...@redhat.com
---
arch/x86/include/asm
keeping it separate from the headers to facilitate backports to people
who wants to backport the kernel part but not the hypervisor, or the other way
around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
CC: Peter
() can be called from
multiple places, not only account_process_tick(), steal time
grabbing is repeated in each account function separatedely.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
CC: Peter Zijlstra pet
, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_para.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index a427bf7
early work, and advise on that - including Stop
now,
you idiot! is very welcome.
TODO:
* Handle unregister over reboots
* Grab a list of current registrations, for migration
* Write documentation
* Check size in hv registerings, to prevent out of boundaries
exploits
Glauber Costa (16
to facilitate backports to people who wants to backport
the kernel part but not the hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/kernel/kvmclock.c | 41 -
1 files changed, 36
it separate to facilitate
backports to people who wants to backport the kernel part but not the
hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Rik van Riel r...@redhat.com
CC: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
CC: Peter Zijlstra pet
the headers to facilitate backports to people who wants to backport the kernel
part
but not the hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 55 +++
1 files
who wants to backport the kernel part but not the
hypervisor, or the other way around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_para.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm
keeping the headers separate to facilitate backports to people
who wants to backport the kernel part but not the hypervisor, or the other way
around.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Avi Kivity a...@redhat.com
---
include/linux/kvm.h | 14 +-
include/linux
On Mon, 2011-01-24 at 19:32 +0100, Peter Zijlstra wrote:
On Mon, 2011-01-24 at 13:06 -0500, Glauber Costa wrote:
This is a first proposal for using steal time information
to influence the scheduler. There are a lot of optimizations
and fine grained adjustments to be done, but it is working
On Mon, 2011-01-24 at 20:51 +0100, Peter Zijlstra wrote:
On Mon, 2011-01-24 at 16:51 -0200, Glauber Costa wrote:
I would really much rather see you change update_rq_clock_task() and
subtract your ns resolution steal time from our wall-time,
update_rq_clock_task() already updates
On Mon, 2011-01-24 at 18:31 -0500, Rik van Riel wrote:
On 01/24/2011 01:06 PM, Glauber Costa wrote:
Register steal time within KVM. Everytime we sample the steal time
information, we update a local variable that tells what was the
last time read. We then account the difference.
Signed
On Mon, 2011-01-24 at 20:26 -0500, Rik van Riel wrote:
On 01/24/2011 08:25 PM, Glauber Costa wrote:
On Mon, 2011-01-24 at 18:31 -0500, Rik van Riel wrote:
On 01/24/2011 01:06 PM, Glauber Costa wrote:
Register steal time within KVM. Everytime we sample the steal time
information, we update
-by: Jan Kiszka jan.kis...@siemens.com
CC: Glauber Costa glom...@redhat.com
looks good.
target-i386/kvm.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d8f26bf..8267655 100644
--- a/target-i386/kvm.c
+++ b/target
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device
On Tue, 2011-01-04 at 12:45 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:43, Glauber Costa wrote:
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
to visualize it
one day.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Glauber Costa glom...@redhat.com
Hi Jan.
I've just recently posted a patch (not sure what was made from it), that
fixes a bug that you reintroduce here.
The bug is: if we call KVM_GET_CLOCK ioctl in pre_save
On Mon, 2011-01-03 at 18:04 +0200, Avi Kivity wrote:
On 01/03/2011 10:33 AM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel
On Mon, 2011-01-03 at 17:30 +0100, Jan Kiszka wrote:
Am 03.01.2011 17:04, Avi Kivity wrote:
On 01/03/2011 10:33 AM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main
...@siemens.com
CC: Glauber Costa glom...@redhat.com
---
target-i386/kvm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d8f26bf..664a4a0 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -453,6 +453,9 @@ void
On Sat, 2011-01-01 at 21:51 +0100, Arjan Koers wrote:
Reduce the number of while-loop iterations (from two to one in the most
common situation)
Signed-off-by: Arjan Koers 0h61vkll2...@xutrox.com
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 42eb330..8f52acb
On Mon, 2011-01-03 at 17:46 +0100, Jan Kiszka wrote:
Am 03.01.2011 17:40, Glauber Costa wrote:
On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
MSR_KVM_ASYNC_PF_EN so
On Sun, Dec 19, 2010 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
Avi,
I recently sent a patch that handles a case much similar to this: when
kvmclock is compiled in the guest,
but not enabled in the host. It somehow
On Tue, 2010-12-14 at 15:34 +0200, Avi Kivity wrote:
On 12/14/2010 02:09 PM, Ulrich Obergfell wrote:
Hi,
This is an RFC through which I would like to get feedback on how the
idea of in-kernel PM Timer would be received.
The current implementation of PM Timer emulation is
On Wed, 2010-12-08 at 17:31 -0200, Marcelo Tosatti wrote:
On Tue, Dec 07, 2010 at 03:12:36PM -0200, Glauber Costa wrote:
On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote:
On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote:
Usually nobody usually thinks about
On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote:
On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote:
Usually nobody usually thinks about that scenario (me included and
specially),
but kvmclock can be actually disabled in the host.
It happens in two scenarios:
1
it only if it's enabled at
machine start.
v2: improvements suggested by Paolo, and patch reordering.
Glauber Costa (2):
Do not register kvmclock savevm section if kvmclock is disabled.
make kvmclock value idempotent for stopped machine
cpus.c|3 +++
qemu-kvm-x86.c| 23
more times,
but this should be fine since vm_stop is not a hot path.
When we do migrate, we'll transfer that value along.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Paolo Bonzini pbonz...@redhat.com
---
qemu-kvm-x86.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
. This patch
achives that by registering this section only if kvmclock is actually
currently enabled in cpuid.
The only caveat is that we have to register the savevm section a little bit
later, since we won't know the final kvmclock state before cpuid gets parsed.
Signed-off-by: Glauber Costa glom
kvm_register_clock, re-using the kvmclock-enabled parameter for that.
This fixes this specific bug, and should protect us from similar
changes in the future.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions
is not a hot path.
When we do migrate, we'll transfer that value along.
Signed-off-by: Glauber Costa glom...@redhat.com
---
cpus.c |4
qemu-kvm-x86.c |7 ++-
qemu-kvm.h |2 ++
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/cpus.c b/cpus.c
index
it only if it's enabled at
machine start.
Thanks
Glauber Costa (2):
make kvmclock value idempotent for stopped machine
Do not register kvmclock savevm section if kvmclock is disabled.
cpus.c|7 +++
qemu-kvm-x86.c| 25 +++--
qemu-kvm.h
. This patch
achives that by registering this section only if kvmclock is actually
currently enabled in cpuid.
The only caveat is that we have to register the savevm section a little bit
later, since we won't know the final kvmclock state before cpuid gets parsed.
Signed-off-by: Glauber Costa glom
On Mon, 2010-11-29 at 08:08 -1000, Zachary Amsden wrote:
On 11/29/2010 07:52 AM, Randy Dunlap wrote:
On 11/29/10 09:47, Zachary Amsden wrote:
On 11/29/2010 06:35 AM, Avi Kivity wrote:
On 11/29/2010 06:33 PM, Randy Dunlap wrote:
On Mon, 22 Nov 2010 13:26:27 -0800
On Tue, 2010-10-26 at 10:14 +0200, Avi Kivity wrote:
On 10/26/2010 01:30 AM, Jeremy Fitzhardinge wrote:
Unfortunately this is breaking Xen save/restore: if you restore on a
host which was booted more recently than the save host, causing the
system time to be smaller. The effect is that the
On Tue, 2010-10-26 at 09:59 -0700, Jeremy Fitzhardinge wrote:
If the guest domain has been suspend/resumed or migrated, then the
system clock backing the pvclock clocksource may revert to a smaller
value (ie, can be non-monotonic across the migration/save-restore).
Make sure we zero
On Mon, Oct 11, 2010 at 10:47:16AM -1000, Zachary Amsden wrote:
On 10/08/2010 10:59 PM, Arjan Koers wrote:
On 2010-10-09 08:29, Michael Tokarev wrote:
...
The result is that no released linux kernel boots
in smp in kvm, which is a linux virtual machine.
That's irony, isn't it?
I wonder
Zach,
vcpu-hv_clock.tsc_timestamp = tsc_timestamp;
vcpu-hv_clock.system_time = kernel_ns + v-kvm-arch.kvmclock_offset;
vcpu-last_kernel_ns = kernel_ns; = (1)
vcpu-last_guest_tsc = tsc_timestamp;
vcpu-hv_clock.flags = 0;
If I understand your intention
On Sun, Sep 12, 2010 at 05:59:45PM +0200, Avi Kivity wrote:
On 09/12/2010 05:31 PM, Anthony Liguori wrote:
On 09/12/2010 01:11 AM, Avi Kivity wrote:
On 09/10/2010 10:48 PM, Anthony Liguori wrote:
I agree, is there any reason not to enable compiling less
into the binary?
There are folks
On Tue, Aug 31, 2010 at 10:11:49AM +0200, Peter Zijlstra wrote:
On Mon, 2010-08-30 at 19:03 -0400, Rik van Riel wrote:
I think it basically comes down to adding sched_clock_unstolen() which
the scheduler can use to measure time a process spends running, and
sched_clock() for measuring
On Sun, Aug 29, 2010 at 12:59:36PM +0300, Avi Kivity wrote:
On 08/26/2010 12:43 AM, Glauber Costa wrote:
This patch proposes a common steal time implementation. When no
steal time is accounted, we just add a branch to the current
accounting code, that shouldn't add much overhead.
When we
On Sun, Aug 29, 2010 at 12:51:40PM +0300, Avi Kivity wrote:
On 08/26/2010 12:43 AM, Glauber Costa wrote:
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens in pvclock vcpu structure.
Signed-off
From: Zachary Amsden zams...@redhat.com
Add a kernel call to get the number of nanoseconds since boot. This
is generally useful enough to make it a generic call.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
include/linux/time.h |1 +
kernel/time/timekeeping.c | 27
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens in pvclock vcpu structure.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|1 +
arch/x86/include/asm/pvclock
of the idea as a whole.
Have a nice review.
Glauber Costa (7):
change headers preparing for steal time
always call kvm_write_guest
measure time out of guest
change kernel accounting to include steal time
kvm steal time implementation
touch softlockup watchdog
tell guest about steal time feature
By measuring time between a vcpu_put and a vcpu_load, we can
estimate how much time did the guest stay out of the cpu.
This is exported to the guest at every clock update.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c
This patch makes sure that kvm_write_guest() is called
at every guest enter. We do not, however, want to update
all the structure at all times, so we add a flag
that basically tells it whether or not to do the whole operation
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c
to the host cpu-hog.
A cpu-hog in the host with no load in the guest, produces 0 % steal time,
with 100 % idle, as one would expect.
Signed-off-by: Glauber Costa glom...@redhat.com
---
include/linux/sched.h |1 +
kernel/sched.c| 29 +
2 files changed, 30 insertions
This patch makes sure that kvm_write_guest() is called
at every guest enter. We do not, however, want to update
all the structure at all times, so we add a flag
that basically tells it whether or not to do the whole operation
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c
This is the proposed kvm-side steal time implementation.
It is migration safe, as it checks flags at every read.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff
Guest kernel will only activate steal time if the host exports it.
Warn the guest about it.
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9d08032..f6a2d74 100644
--- a/arch/x86/kvm/x86.c
+++
to the host cpu-hog.
A cpu-hog in the host with no load in the guest, produces 0 % steal time,
with 100 % idle, as one would expect.
Signed-off-by: Glauber Costa glom...@redhat.com
---
include/linux/sched.h |1 +
kernel/sched.c| 29 +
2 files changed, 30 insertions
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens in pvclock vcpu structure.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|1 +
arch/x86/include/asm/pvclock
With a reliable steal time mechanism, we can tell if we're
out of the cpu for very long, differentiating from the case
that we simply got a real softlockup.
In the case we were out of cpu, the watchdog is fed, making
bogus softlockups disappear.
Signed-off-by: Glauber Costa glom...@redhat.com
With a reliable steal time mechanism, we can tell if we're
out of the cpu for very long, differentiating from the case
that we simply got a real softlockup.
In the case we were out of cpu, the watchdog is fed, making
bogus softlockups disappear.
Signed-off-by: Glauber Costa glom...@redhat.com
Guest kernel will only activate steal time if the host exports it.
Warn the guest about it.
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9d08032..f6a2d74 100644
--- a/arch/x86/kvm/x86.c
+++
This is the proposed kvm-side steal time implementation.
It is migration safe, as it checks flags at every read.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff
By measuring time between a vcpu_put and a vcpu_load, we can
estimate how much time did the guest stay out of the cpu.
This is exported to the guest at every clock update.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c
On Mon, Aug 30, 2010 at 09:45:41AM -0700, Jeremy Fitzhardinge wrote:
On 08/30/2010 09:37 AM, Peter Zijlstra wrote:
Something's gone wrong, I've got at least 15 emails in this thread.
Also, please try again but now with --no-chain-reply-to, threads nested
this deep are useless for
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens in pvclock vcpu structure.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|1 +
arch/x86/include/asm/pvclock
This patch makes sure that kvm_write_guest() is called
at every guest enter. We do not, however, want to update
all the structure at all times, so we add a flag
that basically tells it whether or not to do the whole operation
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c
This is the proposed kvm-side steal time implementation.
It is migration safe, as it checks flags at every read.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff
Guest kernel will only activate steal time if the host exports it.
Warn the guest about it.
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9d08032..f6a2d74 100644
--- a/arch/x86/kvm/x86.c
+++
By measuring time between a vcpu_put and a vcpu_load, we can
estimate how much time did the guest stay out of the cpu.
This is exported to the guest at every clock update.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c
With a reliable steal time mechanism, we can tell if we're
out of the cpu for very long, differentiating from the case
that we simply got a real softlockup.
In the case we were out of cpu, the watchdog is fed, making
bogus softlockups disappear.
Signed-off-by: Glauber Costa glom...@redhat.com
On Mon, Aug 30, 2010 at 06:46:25PM +0200, Peter Zijlstra wrote:
On Mon, 2010-08-30 at 12:06 -0400, Glauber Costa wrote:
This patch proposes a common steal time implementation. When no
steal time is accounted, we just add a branch to the current
accounting code, that shouldn't add much
On Mon, Aug 30, 2010 at 10:33:26AM -0700, Jeremy Fitzhardinge wrote:
On 08/30/2010 09:06 AM, Glauber Costa wrote:
With a reliable steal time mechanism, we can tell if we're
out of the cpu for very long, differentiating from the case
that we simply got a real softlockup.
In the case we
On Fri, Aug 27, 2010 at 01:49:53PM +0800, Jason Wang wrote:
This patch implements two tests for kvmclock. First one check whether
the date of time returned by kvmclock matches the value got from
host. Second one check whether the cycle of kvmclock grows
monotonically in smp guest.
Three
On Fri, Aug 27, 2010 at 01:49:45PM +0800, Jason Wang wrote:
+#define unlikely(x) __builtin_expect(!!(x), 0)
+
+struct pvclock_vcpu_time_info hv_clock[MAX_CPU];
this structure have to be 4-byte aligned. Let the compiler
help you guaranteeing it here.
+#define MAX_CPU 4
+
Any particular
On Fri, Aug 27, 2010 at 01:49:53PM +0800, Jason Wang wrote:
This patch implements two tests for kvmclock. First one check whether
the date of time returned by kvmclock matches the value got from
host. Second one check whether the cycle of kvmclock grows
monotonically in smp guest.
Three
On Fri, Aug 27, 2010 at 01:49:20PM +0800, Jason Wang wrote:
+u64 atomic64_cmpxchg(atomic64_t *v, u64 old, u64 new)
+{
+u64 ret;
+u64 _old = old;
+u64 _new = new;
+
+asm volatile(lock cmpxchgq %1,%2
+ : =a (ret)
+ : r
On Thu, Aug 26, 2010 at 05:47:12PM -0300, Marcelo Tosatti wrote:
Linux does statistical sampling for accounting anyway, so I don't see
it getting much worse.
A cpu hog that sleeps 1us every 1ms.
Imagine a user program, that at periodic intervals, goes to the system.
Under the current
On Thu, Aug 26, 2010 at 05:04:02PM -0400, Rik van Riel wrote:
On 08/26/2010 04:44 PM, Zachary Amsden wrote:
On 08/25/2010 11:43 AM, Glauber Costa wrote:
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens
On Thu, Aug 26, 2010 at 05:19:23PM -0400, Rik van Riel wrote:
On 08/25/2010 05:43 PM, Glauber Costa wrote:
This patch proposes a common steal time implementation. When no
steal time is accounted, we just add a branch to the current
accounting code, that shouldn't add much overhead.
When we
On Thu, Aug 26, 2010 at 04:14:47PM -0500, Anthony Liguori wrote:
On 08/26/2010 03:28 PM, Glauber Costa wrote:
+ if (delta 1000UL)
+ touch_softlockup_watchdog();
+
This will break authentic soft lockup detection whenever qemu processing
takes more than 1s.
This should
On Thu, Aug 26, 2010 at 08:12:40PM -0300, Marcelo Tosatti wrote:
On Thu, Aug 26, 2010 at 06:40:36PM -0300, Glauber Costa wrote:
On Thu, Aug 26, 2010 at 04:14:47PM -0500, Anthony Liguori wrote:
On 08/26/2010 03:28 PM, Glauber Costa wrote:
+ if (delta 1000UL
as a whole.
Have a nice review.
Glauber Costa (6):
change headers preparing for steal time
measure time out of guest
change kernel accounting to include steal time
kvm steal time implementation
touch softlockup watchdog
tell guest about steal time feature
Zachary Amsden (1):
Implement
From: Zachary Amsden zams...@redhat.com
Add a kernel call to get the number of nanoseconds since boot. This
is generally useful enough to make it a generic call.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
include/linux/time.h |1 +
kernel/time/timekeeping.c | 27
This guest/host common patch prepares infrastructure for
the steal time implementation. Some constants are added,
and a name change happens in pvclock vcpu structure.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|1 +
arch/x86/include/asm/pvclock
By measuring time between a vcpu_put and a vcpu_load, we can
estimate how much time did the guest stay out of the cpu.
This is exported to the guest at every clock update.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c
to the host cpu-hog.
A cpu-hog in the host with no load in the guest, produces 0 % steal time,
with 100 % idle, as one would expect.
Signed-off-by: Glauber Costa glom...@redhat.com
---
include/linux/sched.h |1 +
kernel/sched.c| 29 +
2 files changed, 30 insertions
This is the proposed kvm-side steal time implementation.
It is migration safe, as it checks flags at every read.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff
Guest kernel will only activate steal time if the host exports it.
Warn the guest about it.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 680feaa
With a reliable steal time mechanism, we can tell if we're
out of the cpu for very long, differentiating from the case
that we simply got a real softlockup.
In the case we were out of cpu, the watchdog is fed, making
bogus softlockups disappear.
Signed-off-by: Glauber Costa glom...@redhat.com
201 - 300 of 951 matches
Mail list logo
