[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] SMP Guest Proposal RFC




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.