WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] SMP Guest Proposal RFC

To: Rik van Riel <riel@xxxxxxxxxx>
Subject: RE: [Xen-devel] SMP Guest Proposal RFC
From: Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>
Date: Sat, 2 Apr 2005 16:24:13 -0500
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, ryanh@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Orran Y Krieger <okrieg@xxxxxxxxxx>
Delivery-date: Sat, 02 Apr 2005 21:24:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Sat, 2 Apr 2005, Rik van Riel wrote:

> On Fri, 1 Apr 2005, Bryan S Rosenburg wrote:
>
> > This is in fact the mechanism described in Uhlig et al.  Its main drawback
> > is that it does nothing to address the problem of user-level lock-holder
> > preemption.
>
> I'm not sure we need that, futexes seem to take care of the
> user-level problem pretty well.


I understand how futexes help with the problem of preempting user-level lock holders when Linux is running natively, but virtualization complicates the story.  If a user-level thread owns a lock when the hypervisor preempts the virtual processor on which it is running, the state of that thread is buried in the hypervisor and is not available to the Linux kernel.  Even if other threads that try to acquire the lock drop into the kernel, there's nothing that the kernel runnning on other processors can do to get the lock-holder running.  One motivation for the preemption notification mechanism we proposed is that for the most part it avoids suspending virtual processors running user-level code.  User-level threads are always suspended in Linux rather than in the hypervisor, so they're available to be run on other virtual processors.  I would say that preemption notification is needed in order to keep futexes working wel! l as a solution to the user-level lock problem.

- Bryan



Rik van Riel <riel@xxxxxxxxxx>

04/02/2005 10:25 AM

       
        To:        Bryan S Rosenburg/Watson/IBM@IBMUS
        cc:        Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, ryanh@xxxxxxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Orran Y Krieger/Watson/IBM@IBMUS
        Subject:        RE: [Xen-devel] SMP Guest Proposal RFC



On Fri, 1 Apr 2005, Bryan S Rosenburg wrote:

> This is in fact the mechanism described in Uhlig et al.  Its main drawback
> is that it does nothing to address the problem of user-level lock-holder
> preemption.

I'm not sure we need that, futexes seem to take care of the
user-level problem pretty well.

Hmmmm, that makes me wonder if we should use something like
futexes (but simpler, since a virtual machine is one address
space) for xenolinux spinlocks...

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>