[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
> - .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.138 / U:8.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site