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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding

To: habanero@xxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
From: Orran Y Krieger <okrieg@xxxxxxxxxx>
Date: Thu, 9 Jun 2005 15:49:46 -0400
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>, hohnbaum@xxxxxxxxxx, ryanh@xxxxxxxxxx
Delivery-date: Thu, 09 Jun 2005 19:48:56 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42A891AC.7030809@xxxxxxxxxx>
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

habanero@xxxxxxxxxxxxxxxxxxxxxxx wrote on 06/09/2005 02:59:56 PM:

> I take it this assumes nothing else is running on that domain?  I agree
> in this ideal scenerio, it would work (assumming the app threads waiting
> for the lock are not busy waiting), but what about apps which have other
> threads which don't wait on that particular lock, keeping the other cpus
> busy, or a domain with more than one app running?  In those cases the
> load balance would probably not happen, and I would think we need more
> than just the high prio kernel thread to move the desired task to a
> active virtual cpu.

The key place where this came up in our internal discussions was running big HPC apps and big data bases...  In both those cases, the dominant situation is your ideal scenario.  In a multiprogrammed environment, you have the problem even without a hypervisor, i.e., a process holding a lock can be preempted by another process.   Currently, Linux doesn't do any schedular aware synchronizaiton, so presumably this is not viewed as a problem.  If some day this is viewed as a problem, then the preemption upcall could be used by whatever mechanism linux chooses to implement.  I am not convinced that we need a special purpose solution for virtualization...
Xen-devel mailing list