From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753952Ab2DEJQe (ORCPT ); Thu, 5 Apr 2012 05:16:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37872 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875Ab2DEJQc (ORCPT ); Thu, 5 Apr 2012 05:16:32 -0400 Message-ID: <4F7D62CC.9010108@redhat.com> Date: Thu, 05 Apr 2012 12:15:56 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: Thomas Gleixner CC: "H. Peter Anvin" , Raghavendra K T , Ingo Molnar , Linus Torvalds , Peter Zijlstra , the arch/x86 maintainers , LKML , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Konrad Rzeszutek Wilk , Virtualization , Jeremy Fitzhardinge , Stephan Diestelhorst , Srivatsa Vaddagiri , Stefano Stabellini , Attilio Rao Subject: Re: [PATCH RFC V6 0/11] Paravirtualized ticketlocks References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com> <4F7616F5.4070000@zytor.com> <4F7858C0.90405@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/02/2012 12:26 PM, Thomas Gleixner wrote: > > One thing about it is that it can give many false positives. Consider a > > fine-grained spinlock that is being accessed by many threads. That is, > > the lock is taken and released with high frequency, but there is no > > contention, because each vcpu is accessing a different instance. So the > > host scheduler will needlessly delay preemption of vcpus that happen to > > be holding a lock, even though this gains nothing. > > You're talking about per cpu locks, right? I can see the point there, > but per cpu stuff might be worth annotating to avoid this. Or any lock which is simply uncontended. Say a single process is running, the rest of the system is idle. It will take and release many locks; but it can be preempted at any point by the hypervisor with no performance loss. The overhead is arming a timer twice and an extra exit per deferred context switch. Perhaps not much given that you don't see tons of context switches on virt workloads, at least without threaded interrupts (or maybe interrupt threads should override this mechanism, by being realtime threads). > > A second issue may happen with a lock that is taken and released with > > high frequency, with a high hold percentage. The host scheduler may > > always sample the guest in a held state, leading it to conclude that > > it's exceeding its timeout when in fact the lock is held for a short > > time only. > > Well, no. You can avoid that. > > host VCPU > spin_lock() > modify_global_state() > exit > check_global_state() > mark_global_state() > reschedule vcpu > > spin_unlock() > check_global_state() > trigger_exit() > > So when an exit occures in the locked section, then the host can mark > the global state to tell the guest to issue a trap on unlock. Right. How does this nest? Do we trigger the exit on the outermost unlock? -- error compiling committee.c: too many arguments to function