|
|
|
|
|
|
|
|
|
|
xen-ppc-devel
Re: [XenPPC] Why no do_softirq() after external interrupt ?
Yes, I agree, it is strange and could be coded either way.
I doubt there was any real intent here, is is simply how we coded it.
The 970 (our only port) has issues with external interrupt latencies
already, I doubt this code really effects performance.
At the moment we "share" control if the PIC with Dom0 which we are
trying to get away from with the newer kernels so once we have
achieved this "de-coupling" we did plan on revisiting this code path.
I would be happy to take a patch that changed this, especially if you
could demonstrate that it results in lower-latency for interrupts.
-JX
On May 17, 2007, at 9:03 PM, HYEONSEUNG JANG wrote:
There are currently three places in xen code where do_softirq() is
called.
- return to the guest from the hypervisor decrementer interrupt
handler
- return to the guest from a hypercall()
- in idle_loop()
But it is kind of strange that do_softirq() is not called after
external
interrupt handler,
ex_external_continued:
EXCEPTION_SAVE_STATE r1
LOADADDR r12, do_external
mr r3, r1 /* pass pointer to
cpu_user_regs */
subi r1, r1, STACK_FRAME_OVERHEAD /* make a "caller" stack
frame */
CALL_CFUNC r12
addi r1, r1, STACK_FRAME_OVERHEAD /* restore stack to
cpu_user_regs */
b fast_resume
This can cause quite large delay in interrupt processing because
context
switching is done by SCHEDULE_SOFTIRQ.
For example, Let's assume that domU is now running and there is an
external interrupt.
- domU is interrupted and Xen's do_external() is called
- an event channel toward dom0 is set to 'pending'
- domU is resumed by fast_resume
- dom0 is never scheduled even if it has the higher priority until
do_softirq() is called by the next hyperviosr decrementer
interrupt.
When I look at the same parts for the x86 arch, it seems that
softirq is
processed in every 'ret_from_int' which, I think, is expected
behaviour.
Is there anyone who can tell me the reason why do_softirq() is not
called after external interrupt handling? Or is it just a simple
missing(but important) code in XenPPC port ?
- HyeonSeung Jang._______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
|
|