Messages in this thread | | | Date | Thu, 6 Nov 2008 10:19:29 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes |
| |
* Alexander van Heukelum <heukelum@fastmail.fm> wrote:
> > | > | 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.
the cost is 6 cycles instead of 1 cycles. In a codepath that takes thousands of cycles and is often cache-limited.
> 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.
we really want to keep the stack frame consistent between all the context types. We can do things like return-to-userspace-from-irq or schedule-from-irq-initiated-event, etc. - so crossing between these context frames has to be standard and straightforward.
Ingo
| |