All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <juergen.gross@fujitsu-siemens.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Patch: implementing least priority interrupt routing
Date: Tue, 18 Nov 2008 11:37:17 +0100	[thread overview]
Message-ID: <49229ADD.8050903@fujitsu-siemens.com> (raw)
In-Reply-To: <C54846EA.1F52A%keir.fraser@eu.citrix.com>

Keir Fraser wrote:
> On 18/11/08 10:10, "Keir Fraser" <keir.fraser@eu.citrix.com> 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@fujitsu-siemens.com
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

      reply	other threads:[~2008-11-18 10:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18  9:59 Patch: implementing least priority interrupt routing Juergen Gross
2008-11-18 10:10 ` Keir Fraser
2008-11-18 10:18   ` Keir Fraser
2008-11-18 10:37     ` Juergen Gross [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49229ADD.8050903@fujitsu-siemens.com \
    --to=juergen.gross@fujitsu-siemens.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.