[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • 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 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.