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] Linux spin lock enhancement on xen

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Linux spin lock enhancement on xen
From: George Dunlap <dunlapg@xxxxxxxxx>
Date: Tue, 24 Aug 2010 09:08:12 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 24 Aug 2010 01:09:02 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OKtDZH2BZKbq1AGpr6/BUiFjq6Ee6f4zsMTS/rrG6s4=; b=Yu2DE3LsGJZNP9rbAumJAEQrovnai64GPA2j7drgLUxS6MGe5jL5oLLhn0ItdczovM bQDGZLGzpg1zEM8AOWKJsdUjvQxiOh7KwC6qCVsMVnG6ecbl5zvBAwhNyh3cYhIfX6is 8dBgOX+wyuLCTDS3fJxwQwLvbnlbDgKkyuCfs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DJH4WHkiJ0UYIGxVSaXsIHOZLCpekbHCPjqlGD74zmKa2vkJd6/T7eyqaNPF6oz/5r 9VGrELmuXX9exYeytbX4rT4GUqJ8u+rbU3WScsVv11GEmj9IiPiJpJd4E6N3CPYoVLbj sG8A+jZI1Ozqbe7BvTxGneT73ar7bbdVVsg4E=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C891D252.1E4BD%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C6C0C3D.2070508@xxxxxxxx> <C891D252.1E4BD%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Wow, I totally missed this thread.

A couple of thoughts;

Complicated solutions for the scheduler are a really bad idea.  It's
hard enough to predict and debug the side-effects of simple
mechanisms; a complex mechanism is doomed to failure at the outset.

I agree with Jeremy, that the guest shouldn't tell Xen to run a
specific VCPU.  At most it should be something along the lines of, "If
you're going to run any vcpu from this domain, please run vcpu X."

Jeremy, do you think that changes to the HV are necessary, or do you
think that the existing solution is sufficient?  It seems to me like
hinting to the HV to do a directed yield makes more sense than making
the same thing happen via blocking and event channels.  OTOH, that
gives the guest a lot more control over when and how things happen.

Mukesh, did you see the patch by Xiantao Zhang a few days ago,
regarding what to do on an HVM pause instruction?  I thought the
solution he had was interesting: when yielding due to a spinlock,
rather than going to the back of the queue, just go behind one person.
 I think an impleentation of "yield_to" that might make sense in the
credit scheduler is:
* Put the yielding vcpu behind one cpu
* If the yield-to vcpu is not running, pull it to the front within its
priority.  (I.e., if it's UNDER, put it at the front so it runs next;
if it's OVER, make it the first OVER cpu.)



On Wed, Aug 18, 2010 at 6:09 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 18/08/2010 17:37, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> 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
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>