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

    * Alexander van Heukelum <heukelum@fastmail.fm> wrote:

    > On Tue, 4 Nov 2008 13:42:42 +0100, "Ingo Molnar" <mingo@elte.hu> said:
    > >
    > > * Alexander van Heukelum <heukelum@mailshack.com> 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)
    > > > RING0_INT_FRAME
    > > > -vector=0
    > > > -.rept NR_VECTORS
    > > > - ALIGN
    > > > - .if vector
    > > > - CFI_ADJUST_CFA_OFFSET -4
    > > > - .endif
    > > > -1: pushl $~(vector)
    > > > - CFI_ADJUST_CFA_OFFSET 4
    > > > + 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).
    >
    > The way it is written now is just so I did not have to change
    > common_interrupt (to keep changes small). All those accesses so
    > close together will cost some cycles, but much can be avoided if it
    > is integrated. If the precise content of the stack can be changed,
    > this could be as simple as "push %cs". Even that can be delayed,
    > because the content of the cs register will still be there.
    >
    > Note that the specialized interrupts (including page fault, etc.)
    > will not go via this path. As far as I understand now, it is only
    > the interrupts from external devices that normally go via
    > common_interrupt. There I think the overhead is really tiny compared
    > to the rest of the handling of the interrupt.

    no complaints from me about the cleanup/simplification effect - that's
    really great. To make the reasoning all iron-clad please post timings
    of "push %cs" costs measured via RDTSC or so - can be done in
    user-space as well. (you can simulate the entry+exit sequence in
    user-space as well and prove that the overhead is near zero.) In the
    end it could all even be faster (perhaps), besides smaller.

    ( another advantage is that the 6 bytes GDT descriptor is more
    compressed and hence uses up less L1/L2 cache footprint than the
    larger (~7 byte) trampolines we have at the moment. )

    plus it's possible to observe the typical cost of irqs from user-space
    as well: run a task on a single CPU and save away all the RDTSC deltas
    that are larger than ~10 cycles - these will be the IRQ entry costs.
    Print out these deltas after 60 seconds of runtime (or something like
    that), and look at the histogram.

    Ingo


    \
     
     \ /
      Last update: 2008-11-04 15:03    [W:0.028 / U:0.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site