From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH RFC 0/2] kvm: Improving undercommit,overcommit scenarios in PLE handler Date: Wed, 26 Sep 2012 15:45:10 +0200 Message-ID: <1348667110.3881.108.camel@twins> References: <1348486479.11847.46.camel@twins> <50604988.2030506@linux.vnet.ibm.com> <1348490165.11847.58.camel@twins> <50606050.309@linux.vnet.ibm.com> <1348494895.11847.64.camel@twins> <50608176.1040805@redhat.com> <1348502600.11847.90.camel@twins> <5060883C.4050901@redhat.com> <20120926132013.GB7633@turtle.usersys.redhat.com> <1348665971.3881.102.camel@twins> <20120926133905.GA8842@turtle.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Avi Kivity , Raghavendra K T , "H. Peter Anvin" , Marcelo Tosatti , Ingo Molnar , Rik van Riel , Srikar , "Nikunj A. Dadhania" , KVM , Jiannan Ouyang , chegu vinod , "Andrew M. Theurer" , LKML , Srivatsa Vaddagiri , Gleb Natapov To: Andrew Jones Return-path: In-Reply-To: <20120926133905.GA8842@turtle.usersys.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Wed, 2012-09-26 at 15:39 +0200, Andrew Jones wrote: > On Wed, Sep 26, 2012 at 03:26:11PM +0200, Peter Zijlstra wrote: > > On Wed, 2012-09-26 at 15:20 +0200, Andrew Jones wrote: > > > Wouldn't a clean solution be to promote a task's scheduler > > > class to the spinner class when we PLE (or come from some special > > > syscall > > > for userspace spinlocks?)? > > > > Userspace spinlocks are typically employed to avoid syscalls.. > > I'm guessing there could be a slow path - spin N times and then give > up and yield. Much better they should do a blocking futex call or so, once you do the syscall you're in kernel space anyway and have paid the transition cost. > > > > > That class would be higher priority than the > > > fair class and would schedule in FIFO order, but it would only run its > > > tasks for short periods before switching. > > > > Since lock hold times aren't limited, esp. for things like userspace > > 'spin' locks, you've got a very good denial of service / opportunity for > > abuse right there. > > Maybe add some throttling to avoid overuse/maliciousness? At which point you're pretty much back to where you started. A much better approach is using things like priority inheritance, which can be extended to cover the fair class just fine.. Also note that user-space spinning is inherently prone to live-locks when combined with the static priority RT scheduling classes. In general its a very bad idea..