Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

["Alexander van Heukelum" <heukelum@fastmail.fm>]

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.

> 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)

I already had jeremy@xensource.com for exactly this reason ;). 

Greetings,
    Alexander

> 	Ingo
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service