From owner-svn-src-user@FreeBSD.ORG Thu Feb 5 16:10:56 2009 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 531991065670; Thu, 5 Feb 2009 16:10:56 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFE38FC18; Thu, 5 Feb 2009 16:10:56 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 4987C3F9F; Thu, 5 Feb 2009 16:10:19 +0000 (GMT) Message-Id: <75E8FE57-7235-4F4D-813B-41BEFE7907C5@rabson.org> From: Doug Rabson To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 16:10:54 +0000 References: <200902051509.n15F9gCj030370@svn.freebsd.org> X-Mailer: Apple Mail (2.930.3) Cc: Doug Rabson , src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r188153 - user/dfr/xenhvm/6/sys/amd64/conf X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:10:56 -0000 On 5 Feb 2009, at 15:39, Robert Watson wrote: > > On Thu, 5 Feb 2009, Doug Rabson wrote: > >> Adaptive mutex spinning turns out to be very slightly slower on >> Xen, probably >> due to scheduling conflicts with other guests within the same >> hypervisor. > > Part of the effectiveness of adaptive mutexes is in their being able > to tell with a single read whether or not the thread owning the lock > is (likely) in execution. This is complicated with a hypervisor > because although the FreeBSD kernel has the thread in the run state > doesn't mean that the hypervisor has FreeBSD in the run state. Is > there any way we could provide similar hints here? As core density > goes up, people may over-commit hardware resources less, using Xen > for assigning subsets of the core pool to particular VMs as opposed > to time-sharing individual cores, in which case we'd like adaptive > mutexes to work... This is indeed the key problem. At least with Xen, there is no way of telling that the vcpu which is ostensibly executing the lock owning thread is actually scheduled onto a physical cpu by the hypervisor. Its something I will encourage the Xen people to improve on in future.