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

[Alexander van Heukelum]

On Tue, 4 Nov 2008 20:13:46 +0300, "Cyrill Gorcunov"
<gorcunov@xxxxxxxxx> said:
> [Ingo Molnar - Tue, Nov 04, 2008 at 05:58:11PM +0100]
> | 
> | * Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
> | 
> | > [Alexander van Heukelum - Tue, Nov 04, 2008 at 05:23:09PM +0100]
> | > ...
> | > | 
> | > | I did some timings using the little program below (32-bit only),
> doing
> | > | 1024 times the same sequence. TEST1 is just pushing a constant onto
> | > | the stack; TEST2 is pushing the cs register; TEST3 is the sequence
> | > | from the patch to extract the vector number from the cs register.
> | > | 
> | > | Opteron    (cycles): 1024 / 1157 / 3527
> | > | Xeon E5345 (cycles): 1092 / 1085 / 6622
> | > | Athlon XP  (cycles): 1028 / 1166 / 5192
> | > 
> | > Xeon is defenitely out of luck :-)
> | 
> | it's still OK - i.e. no outrageous showstopper overhead anywhere in 
> | that instruction sequence. The total round-trip overhead is what will 
> | matter most.
> | 
> | 	Ingo
> | 
> 
> Don't get me wrong please, I really like what Alexander have done!
> But frankly six time slower is a bit scarying me.

Thanks again ;). Now it _is_ six times slower to do this tiny
piece of code... But please keep in mind all the activity that
follows to save the current data segment registers (the stack
segment and code segment are saved automatically), the general
purpose registers and to load most of the data segments with
kernel-space values. And looking at it now... do_IRQ is also
not exactly trivial.

Also, I kept the information that is saved on the stack
exactly the same. If this is not a requirement, "push %cs"
is what is left of this expensive (6 cycle!) sequence.
Even that could be unnecessary if the stack layout can
be changed... But I'ld like to consider that separately.

Greetings,
    Alexander

> 		- Cyrill -
-- 
  Alexander van Heukelum
  heukelum@xxxxxxxxxxx

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/