Re: [PATCH 2/2] Add MSR Bitmap support in VMX

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

Li, Xin B wrote:
>> -----Original Message-----
>> From: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>> [mailto:kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>> Ulrich Drepper
>> Sent: Friday, August 03, 2007 2:24 AM
>> To: Nakajima, Jun
>> Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> Subject: Re: [kvm-devel] [PATCH 2/2] Add MSR Bitmap support in VMX
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Nakajima, Jun wrote:
>>     
>>>> Looking at the Linux context switch code, it can bang on MSR_FS_BASE
>>>>         
>>> and
>>>       
>>>> MSR_KERNEL_GS_BASE. A high context switch rate between 
>>>>         
>> threads (which
>>     
>>>> use %gs or %fs) can show an improvement with this.  Things 
>>>>         
>> like kbuild
>>     
>>>> probably won't as they use single threaded processes.
>>>>         
>>> Right. 
>>>       
>> In Linux there is no difference between single- and multi-threaded
>> processes when it comes to setting up segment registers.  Every x86-64
>> process uses %fs for TLS and every x86 process uses %gs.  There are
>> always variables accessed this way (errno, for instance).
>>
>>     
>
> I have to say, the benefit form _no_ VMExits on these VMExits are not so
> obviously, because each context switch invloves a guest CR3 update, then
> a page fault vmexit is triggered and a shadow handling is involved,
> which is the major cost of guest context switch.
>   

A small test program demonstrates the benefit.  In thread mode, it takes 
5 seconds without the patch and 3 seconds with the patch applied (200K 
and ~0 exits/sec).  In fork mode, it takes 10 seconds without the patch 
and 7.2 seconds with the patch (420K and 280K exits/sec).  Note that 
with this test there are no page fault exits, only cr and msr exits 
(with the threaded mode avoiding the cr exit).

So the patch is quite measurable on microbenchmarks -- in threaded mode 
we're at native performance.

-- 
error compiling committee.c: too many arguments to function


[-- Attachment #2: cswitch.c --]
[-- Type: text/x-csrc, Size: 573 bytes --]


#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>

static int p1[2], p2[2];

#define N 1000000

void *server(void *_)
{
	char buf;

	while (read(p1[0], &buf, 1) == 1)
		write(p2[1], &buf, 1);
}

void client()
{
	char buf;
	int i;

	for (i = 0; i < N; ++i) {
		write(p1[1], &buf, 1);
		read(p2[0], &buf, 1);
	}
}

int main(int ac, char **av)
{
	pthread_t thread;

	pipe(p1);
	pipe(p2);

	if (ac < 2 || strcmp(av[1], "fork") != 0)
		pthread_create(&thread, NULL, server, NULL);
	else
		if (fork() == 0) {
			server(NULL);
			return 0;
		}
	client();
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel