On Wed, Jan 30, 2008 at 09:26:53AM +0100, Gerd Hoffmann wrote:
> Marcelo Tosatti wrote:
> > And this is against a changed x86.git -mm tree (with pvops64 patches).
> > I'll send the PTE-write-via-hypercall patches soon and will rebase on
> > top of that (the CR3 cache needs more testing/tuning appar
Avi Kivity wrote:
> [fairly amazing results. how do they compare to xen?]
Didn't benchmark it side-by-side yet. Most likely xenner is still
noticeable slower on 64bit (32bit should be roughly comparable). I also
wouldn't surprised if you see different results on different workloads.
xen mangl
Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
>> I've passed in a physical address. The vmx_cr3_cache_msr() function has
>> a gva_to_page() call which makes me suspect it expects a virtual
>> address.
>>
>
> Confirmed. When passing in a virtual address it works.
> And it gives me a nice s
Gerd Hoffmann wrote:
> I've passed in a physical address. The vmx_cr3_cache_msr() function has
> a gva_to_page() call which makes me suspect it expects a virtual
> address.
Confirmed. When passing in a virtual address it works.
And it gives me a nice speedup for kernel builds:
rhel5-64 kraxel ~
Marcelo Tosatti wrote:
> And this is against a changed x86.git -mm tree (with pvops64 patches).
> I'll send the PTE-write-via-hypercall patches soon and will rebase on
> top of that (the CR3 cache needs more testing/tuning apparently).
Oops for sale ;)
Triggered by guests wrmsr, looks like some e
On Tue, Jan 29, 2008 at 11:28:00AM +0100, Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
> > Hmm, what kvm version is this against? latest git I guess? After
> > applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
>
> Looks like the mmu.h chunk is missing in the patch.
Yes
Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
>> Hmm, what kvm version is this against? latest git I guess? After
>> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
>
> Looks like the mmu.h chunk is missing in the patch.
Hmm, and x86.c looks incomplete too. vcpu->arc
Gerd Hoffmann wrote:
> Hmm, what kvm version is this against? latest git I guess? After
> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
Looks like the mmu.h chunk is missing in the patch.
cheers,
Gerd
Marcelo Tosatti wrote:
> Hi,
>
> The CR3 cache feature of VMX CPU's does not seem to increase
> context switch performance significantly as it did in the original
> implementation (http://lkml.org/lkml/2007/1/5/205).
>
> The following is similar to the original, but it also caches roots for
> 4-l
On Mon, Jan 28, 2008 at 06:37:08PM +0100, Ingo Molnar wrote:
> try running your shell on one CPU:
>
> taskset -p 1 $$
>
> that should give you the 'raw' single-CPU context switch results.
With pinning ~= 3.30, and on an UP guest still ~= 6. I'll check the
vmexits later, thanks.
---
* Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> > when i did the testing then i was able to get zero VM exits in the
> > lat_ctx hotpath and get the same performance as on native. The above
> > numbers you got suggest that this is not the case. (your lat_ctx
> > numbers on native are probably a
On Mon, Jan 28, 2008 at 06:17:34PM +0100, Ingo Molnar wrote:
>
> * Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>
> > lat_ctx numbers (output is "nr-procs overhead-in-us"):
> >
> > cr3-cache:
> > "size=0k ovr=1.30
> > 2 6.63
> > "size=0k ovr=1.31
> > 4 7.43
> > "size=0k ovr=1.32
> > 8 11.02
>
> w
Marcelo Tosatti wrote:
> So the questions are, why the benefit is not similar (vm-exit's are now
> way cheaper?) and is it worth to merge this given the results?
>
Yes, vmexits are now about 5 times faster compared to older kvm.
> +
> +/*
> + * Avoid the VM exit upon cr3 load by using the cac
* Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> lat_ctx numbers (output is "nr-procs overhead-in-us"):
>
> cr3-cache:
> "size=0k ovr=1.30
> 2 6.63
> "size=0k ovr=1.31
> 4 7.43
> "size=0k ovr=1.32
> 8 11.02
when i did the testing then i was able to get zero VM exits in the
lat_ctx hotpath and ge
Hi,
The CR3 cache feature of VMX CPU's does not seem to increase
context switch performance significantly as it did in the original
implementation (http://lkml.org/lkml/2007/1/5/205).
The following is similar to the original, but it also caches roots for
4-level pagetables on x86-64, and clearing
15 matches
Mail list logo
