From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks Date: Mon, 17 Oct 2011 09:33:26 -0700 Message-ID: <4E9C58D6.9010103@zytor.com> References: <1318503245.24856.12.camel@twins> <4E971580.6030300@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Peter Zijlstra , Linus Torvalds , Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List , Nick Piggin , Avi Kivity , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Jeremy Fitzhardinge To: Jeremy Fitzhardinge Return-path: Received: from terminus.zytor.com ([198.137.202.10]:34188 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753525Ab1JQQea (ORCPT ); Mon, 17 Oct 2011 12:34:30 -0400 In-Reply-To: <4E971580.6030300@goop.org> Sender: kvm-owner@vger.kernel.org List-ID: On 10/13/2011 09:44 AM, Jeremy Fitzhardinge wrote: > > Yeah, that's a good question. There are three mechanisms with somewhat > overlapping concerns: > > * alternative() > * pvops patching > * jump_labels > > Alternative() is for low-level instruction substitution, and really only > makes sense at the assembler level with one or two instructions. > > pvops is basically a collection of ordinary _ops structures full of > function pointers, but it has a layer of patching to help optimise it. > In the common case, this just replaces an indirect call with a direct > one, but in some special cases it can inline code. This is used for > small, extremely performance-critical things like cli/sti, but it > awkward to use in general because you have to specify the inlined code > as a parameterless asm. > > Jump_labels is basically an efficient way of doing conditionals > predicated on rarely-changed booleans - so it's similar to pvops in that > it is effectively a very ordinary C construct optimised by dynamic code > patching. Then there is static_cpu_has(), which is basically jump labels implemented using the alternatives mechanism. If nothing else it would be good to: 1. Make more general use of ops patching; 2. Merge mechanisms where practical. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.