From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: Linux spin lock enhancement on xen Date: Tue, 17 Aug 2010 18:58:16 -0700 Message-ID: <20100817185816.6c31ab7e@mantra.us.oracle.com> References: <20100816183357.08623c4c@mantra.us.oracle.com> <4C6A5C1C02000078000104D1@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C6A5C1C02000078000104D1@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Tue, 17 Aug 2010 08:53:32 +0100 "Jan Beulich" wrote: > >>> On 17.08.10 at 03:33, Mukesh Rathor > >>> wrote: > > A mere vcpu_kick()+do_yield() seems pretty simplistic to me - if the > current vCPU still has higher priority than the one kicked you'll > achieve nothing. Instead, I think you really want to offer the > current vCPU's time slice to the target, making sure the target > yields back as soon as it released the lock (thus transferring the > borrowed time slice back to where it belongs). True, that is phase II enhancement. > And then, without using ticket locks, you likely increase unfairness > (as any other actively running vCPU going for the same lock will > have much better chances of acquiring it than the vCPU that > originally tried to and yielded), including the risk of starvation. Please see other thread on my thoughts on this. > Still, I'm glad to see we're not the only ones wanting a directed > yield capability in Xen. > > >+struct sched_yield_to { > >+ unsigned int version; > >+ unsigned int vcpu_id; > >+}; > > Why do you need a version field here, the more as it doesn't > appear to get read by the hypervisor. No reason, just forgot to remove it. thanks, Mukesh