From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757397Ab2GKLwk (ORCPT ); Wed, 11 Jul 2012 07:52:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43520 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753958Ab2GKLwi convert rfc822-to-8bit (ORCPT ); Wed, 11 Jul 2012 07:52:38 -0400 Subject: Re: [PATCH RFC 0/2] kvm: Improving directed yield in PLE handler Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=US-ASCII From: Alexander Graf In-Reply-To: <4FFD621D.5090607@redhat.com> Date: Wed, 11 Jul 2012 13:52:26 +0200 Cc: Christian Borntraeger , Raghavendra K T , "H. Peter Anvin" , Thomas Gleixner , Marcelo Tosatti , Ingo Molnar , Rik van Riel , S390 , Carsten Otte , KVM , chegu vinod , "Andrew M. Theurer" , LKML , X86 , Gleb Natapov , linux390@de.ibm.com, Srivatsa Vaddagiri , Joerg Roedel , Christian Ehrhardt , Paul Mackerras , Benjamin Herrenschmidt Content-Transfer-Encoding: 7BIT Message-Id: <794FFD35-579D-48CE-890F-8FCC785032F3@suse.de> References: <20120709062012.24030.37154.sendpatchset@codeblue> <4FFA8E5E.3070108@de.ibm.com> <4FFD422B.9060008@redhat.com> <4FFD52CD.7040403@de.ibm.com> <4FFD5DA3.3010001@redhat.com> <39DA3B9A-87D6-4EA5-B1FF-B6E30733EF7B@suse.de> <4FFD621D.5090607@redhat.com> To: Avi Kivity X-Mailer: Apple Mail (2.1278) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11.07.2012, at 13:23, Avi Kivity wrote: > On 07/11/2012 02:16 PM, Alexander Graf wrote: >>> >>>> yes the data structure itself seems based on the algorithm >>>> and not on arch specific things. That should work. If we move that to common >>>> code then s390 will use that scheme automatically for the cases were we call >>>> kvm_vcpu_on_spin(). All others archs as well. >>> >>> ARM doesn't have an instruction for cpu_relax(), so it can't intercept >>> it. Given ppc's dislike of overcommit, >> >> What dislike of overcommit? > > I understood ppc virtualization is more of the partitioning sort. > Perhaps I misunderstood it. But the reliance on device assignment, the > restrictions on scheduling, etc. all point to it. Well, you need to distinguish the different PPC targets here. In the embedded world, partitioning is obviously the biggest use case, though overcommit is possible. For big servers however, we usually do want overcommit and we do support it within the constraints hardware gives us. It's really no different from x86 when it comes to the use case wideness :). > >> >>> and the way it implements cpu_relax() by adjusting hw thread priority, >> >> Yeah, I don't think we can intercept relaxing. > > ... and the lack of ability to intercept cpu_relax() ... > >> It's basically a nop-like instruction that gives hardware hints on its current priorities. > > That's what x88 PAUSE does. But we can intercept it (and not just any > execution - we can restrict intercept to tight loops executed more than > a specific number of times). Yeah, it's pretty hard to fetch that information from PPC, since unlike x86 we split the hint from the loop. But I'll let Ben speak to that, he certainly knows way better how the hardware works. > >> That said, we can always add PV code. > > Sure, but that's defeated by advancements like self-tuning PLE exits. > It's hard to get this right. Well, eventually everything we do in PV is going to be moot as soon as hardware catches up. In most cases from what I've seen it's only useful as an interim solution. But for that time it's good to have :). Alex