From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/5] KVM: Add hypercall queue for paravirt_ops implementation Date: Mon, 18 Jun 2007 12:07:19 +0300 Message-ID: <46764B47.5060403@qumranet.com> References: <4675F462.1010708@codemonkey.ws> <4675F568.90608@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4675F568.90608-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Cc: kvm-devel , virtualization List-Id: virtualization@lists.linuxfoundation.org Anthony Liguori wrote: > Implemented a hypercall queue that can be used when paravirt_ops lazy mode > is enabled. This patch enables queueing of MMU write operations and CR > updates. This results in about a 50% bump in kernbench performance. > Nice! But 50%? a kernel build is at native-25%, so we're now 25% faster than native? > + state->vmca->queue_gpa = __pa(state->queue); > + state->vmca->max_queue_index > + = (PAGE_SIZE / sizeof(struct kvm_hypercall_entry)); > Why not pass the queue address as an argument to KVM_HYPERCALL_FLUSH? That reduces the amount of setup, and allows more flexibility (e.g. multiple queues). I'm not thrilled with having queues of hypercalls; instead I'd prefer queues of mmu operations, but I guess it won't do any good to go against prevailing custom here. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/