From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: Linux spin lock enhancement on xen Date: Wed, 18 Aug 2010 19:52:31 -0700 Message-ID: <20100818195231.69e7df0d@mantra.us.oracle.com> References: <4C6C0C3D.2070508@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Jeremy Fitzhardinge , "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, 18 Aug 2010 18:09:22 +0100 Keir Fraser wrote: > On 18/08/2010 17:37, "Jeremy Fitzhardinge" wrote: > > > I don't see why the guest should micromanage Xen's scheduler > > decisions. If a VCPU is waiting for another VCPU and can put itself > > to sleep in the meantime, then its up to Xen to take advantage of > > that newly freed PCPU to schedule something. It may decide to run > > something in your domain that's runnable, or it may decide to run > > something else. There's no reason why the spinlock holder is the > > best VCPU to run overall, or even the best VCPU in your domain. > > > > My view is you should just put any VCPU which has nothing to do to > > sleep, and let Xen sort out the scheduling of the remainder. > > Yeah, I'm no fan of yield or yield-to type operations. I'd reserve > the right to implement both of them as no-op. > > -- Keir > I think making them advisory makes sense. Ultimately xen decides. thanks, Mukesh