[lkml]   [2008]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    * Alexander van Heukelum <> wrote:

    > Hi all,
    > An x86 processor handles an interrupt (from an external source,
    > software generated or due to an exception), depending on the
    > contents if the IDT. Normally the IDT contains mostly interrupt
    > gates. Linux points each interrupt gate to a unique function. Some
    > are specific to some task (handling traps, IPI's, ...), the others
    > are stubs that push the interrupt number to the stack and jump to
    > 'common_interrupt'.
    > This patch removes the need for the stubs.

    hm, the cost would be this new code:

    > +.p2align
    > +ENTRY(maininterrupt)
    > -vector=0
    > -.rept NR_VECTORS
    > - ALIGN
    > - .if vector
    > - .endif
    > -1: pushl $~(vector)
    > + push %eax
    > + push %eax
    > + mov %cs,%eax
    > + shr $3,%eax
    > + and $0xff,%eax
    > + not %eax
    > + mov %eax,4(%esp)
    > + pop %eax
    > jmp common_interrupt

    .. which we were able to avoid before. A couple of segment register
    accesses, shifts, etc to calculate the vector - each of which can be
    quite costly (especially the segment register access - this is a
    relatively rare instruction pattern).

    I'm not unconvicable, but we need to be conservative here: could you
    try to measure the full before/after cost of IRQ entry, to the cycle
    level? I'm curious what the performance impact is.

    Also, this makes life probably a bit harder for Xen, which assumes
    that the GDT of the guest OS is small-ish. (Jeremy Cc:-ed)


     \ /
      Last update: 2008-11-04 13:45    [W:0.026 / U:0.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site