Xen devel - Nov 2008 - Patch: implementing least priority interrupt routing

Hi,

the attached patch implements interrupt routing to least priority processor
for HVM domains.
Instead of round robin the vcpu with the lowest processor priority is selected
for the interrupt. If multiple vcpus share the same low priority interrupts
are distributed between those round robin.
Tested with BS2000 domain (3 vcpus, idle processors are now preferred
interrupt target).

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


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

On 18/11/08 09:59, "Juergen Gross"
<juergen.gross@fujitsu-siemens.com>
wrote:
> the attached patch implements interrupt routing to least priority processor
> for HVM domains.
> Instead of round robin the vcpu with the lowest processor priority is
selected
> for the interrupt. If multiple vcpus share the same low priority interrupts
> are distributed between those round robin.
> Tested with BS2000 domain (3 vcpus, idle processors are now preferred
> interrupt target).
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.

 -- Keir



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

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).

 -- Keir



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

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

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