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@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel


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

Reply via email to