WARNING - OLD ARCHIVES

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

xen-devel

Re: [Xen-devel] [Patch 1 of 2]: PV-domain SMP performance XEN-part

To: George Dunlap <dunlapg@xxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 1 of 2]: PV-domain SMP performance XEN-part
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 22 Dec 2008 07:10:08 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 21 Dec 2008 22:11:05 -0800
Domainkey-signature: s=s768; d=fujitsu-siemens.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=HQNVuX8aEeYhga+1EM1vWpJISwWzMvSJ5Z31uwSKGEo1lXHpNGQJo5jH QZsu99CEKE35JHuYI7x5fVpR02zEBhX0/O3cWnRGrLGd8QBwmbj/l65Kb RNu+Y31xgxf7UFk;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0812190742u423824fdq73ce06cab0eb7427@xxxxxxxxxxxxxx>
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>
Organization: Fujitsu Siemens Computers
References: <4948EFC5.8050701@xxxxxxxxxxxxxxxxxxx> <de76405a0812190742u423824fdq73ce06cab0eb7427@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)
George Dunlap wrote:
> The idea might be interesting, but this implementation needs some
> work.  Xen shouldn't be reading a guest-writable bit of memory to
> determine if it's already delayed the guest; it needs to store that
> information somewhere else.  As it is, a rogue guest could extend its
> time indefinitely by just writing 0 there every couple hundred
> instructions.

Thanks for finding this one!
The correction is quite simple, I can just use sd->delay_desched for
this purpose instead.

> 
> It should probably be something taken care of in the individual
> schedulers, rather than in the abstract scheduling code.
> 
> At any rate, let's see if there's a significant performance difference
> between this and yield-after-spinning-awhile, and then we can work on
> the architecture.

Agreed.


Juergen

-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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