* Alexander van Heukelum <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Nov 2008 13:42:42 +0100, "Ingo Molnar" <[EMAIL PROTECTED]> said:
> >
> > * Alexander van Heukelum <[EMAIL PROTECTED]> 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
_______________________________________________
Lguest mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/lguest
