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] Dont' round-robin the callback interrupt

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Dont' round-robin the callback interrupt
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Tue, 13 Jul 2010 06:59:34 +0200
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 12 Jul 2010 22:00:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1278997222; x=1310533222; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C3BF2B6.4050807@xxxxxxxxxxxxxx>|Date:=20 Tue,=2013=20Jul=202010=2006:59:34=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx> |CC:=20Paul=20Durrant=20<Paul.Durrant@xxxxxxxxxx>,=20=0D =0A=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lists. xensource.com>,=0D=0A=20Tim=20Deegan=20<Tim.Deegan@xxxxxx rix.com>|Subject:=20Re:=20[Xen-devel]=20[PATCH]=20Dont' =20round-robin=20the=20callback=20interrupt|References: =20<C861124F.1A721%keir.fraser@xxxxxxxxxxxxx> |In-Reply-To:=20<C861124F.1A721%keir.fraser@xxxxxxxxxxxxx >|Content-Transfer-Encoding:=207bit; bh=G/u5hteA6zepGBQobMwQBhDHEdolFbweKG926A9g32I=; b=g4SmQyhFfU+LYRIpZenOiJhJrOG8gaVJBdPe4NnyFH523dAto98FMw0q aSYnAe7fSON6YXV78i43X9j+L3xkSbxFbWU/V2vlqoyQApQGl/uvSoJPC laCUOHMQ+LDZNJ3XSqidc99EewGLmEUnyLx++rwffE9GAfNyDlaPnT+5W qyjk2F4O5uXrfSpmeOW4Q+LtiOl7TvlWLQ6MPAw14gycb150e6O1DXoHa v6/PwGPlosY9Hhi0+H1V/tVuRUd1v;
Domainkey-signature: s=s1536a; d=ts.fujitsu.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:Content-Type:Content-Transfer-Encoding; b=IqeoFIbSlfzaeHpdFGW4xlqnZNQrlm6RLaUVPS6z9sqXcVGcYcvlx8V4 rCCzbt9shtAs0BcXftt70jZVU20fu0WORBQGpC/923oZNzpi6WuPeFoDU /YDt7nayZL3SmmY2C7LIme3LU/QesGfq2ES8BMtAARvWGrRA6ODWszMcK uyn+RjzOPKG1YU3BPJAPe8k9Vcmb7GS/g5L7CyWrF0/V2+R/qgq5EmK9j UtjYdzLcFxzqddjOD9WYO1jpwf3jj;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C861124F.1A721%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>
Organization: Fujitsu Technology Solutions
References: <C861124F.1A721%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5
On 07/12/2010 07:41 PM, Keir Fraser wrote:
On 12/07/2010 18:17, "Keir Fraser"<keir.fraser@xxxxxxxxxxxxx>  wrote:

   However, that's not the motivation for this patch. In the windows code, we
only bind event channels to vcpu 0 since we cannot get callback interrupts on
multiple vcpus simultaneously, since the interrupt is level sensitive. Thus
round-robining is wasteful in terms of kicking certain data structures
between
caches (assuming a reasonably constant vcpu ->  pcpu mapping).

Surely that argument can be made for any interrupt that is set up to
round-robin among multiple CPUs? Obviously in the PV drivers case the
event-channel IRQ is probably the only significant source of round-robin
interrupts. But I don't see that it's special in any other way.

Further, the correct semantics for LowestPrio delivery was implemented by
Juergen Gross at Fujitsu for a reason. Cc'ing him. I suspect he will say
that relaxing the delivery semantics will cause something he cares about to
break.

Thanks for CC'ing me, Keir.
Selecting different CPUs gives at least our BS2000 system a performance win of
a few percent. As Keir already said, that's the reason I implemented the LPP
delivery of interrupts.
If you really need a different interrupt delivery behaviour I would at least
recommend a per-domain parameter for violating the correct semantics using the
LPP delivery as default.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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