Xen project Mailing List

Re: [Xen-devel] Patch: implementing least priority interrupt routing

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>

From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>

Date: Tue, 18 Nov 2008 11:37:17 +0100

Delivery-date: Tue, 18 Nov 2008 02:37:40 -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=E+WQ/keJbfFu8mbFh3dD0u4nNSu5b1a30Gv0lPlr1PHR+iminBjWtk7D MHwaRrhTrempJhdmKo0rbwZW9oLapJ3JGWJRHmnyq69uCZQIjQFFKMpTs 09JzqcSNDAepxQU;

List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Keir Fraser wrote: > On 18/11/08 10:10, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote: > >> Where idle means 'not processing an interrupt'. Which ought to be by far the >> most common case even for a non-idle CPU. Does this really improve load >> balancing all that much? Does BS2000 spend lots of time in IRQ context? >> >> My fear is that extra complexity here slows down dest_lowprio for all OSes >> (and it's used by a lot of OSes) for every ExtInt delivered. > > That fear is probably unfounded actually, given we scan a vcpu's IRR bitmap > on *every* vmentry currently. Still it would be nice to know the motivation > behind this patch (beyond 'it's nice to behave like native hardware'). We > might still find a cheaper method with similar or better benefit (e.g., > check vcpu_runnable() to find idle VCPUs is cheaper and may be more > accurate). We are using the lower 4 bits of the task priority register in the LAPIC to control the interrupt routing. So "idle" really means idle. We have other priorities as well. In our system we support /390 user applications via a JIT-compiler which has to ensure /390 instruction semantics even in case of interrupts (this means interrupts have to be delayed until a /390 instruction boundary has been reached). This results in a rather high interrupt latency when a /390 application is just running on the processor. If however the processor is just executing BS2000 system code this restriction no longer applies. So we are using a higher task priority when executing /390 code resulting in less interruptions and thus better performance. I hope things are clearer now. 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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.