Messages in this thread | | | From | "Alexander van Heukelum" <> | Subject | Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes | Date | Tue, 04 Nov 2008 17:45:06 +0100 |
| |
On Tue, 4 Nov 2008 17:36:36 +0100, "Ingo Molnar" <mingo@elte.hu> said: > > * Alexander van Heukelum <heukelum@fastmail.fm> wrote: > > > I wonder how the time needed for reading the GDT segments balances > > against the time needed due to the extra redirection due to running > > the stubs. I'ld be interested if the difference can be measured with > > the current implementation. (I really need to highjack a machine to > > do some measurements; I hoped someone would do it before I got to it > > ;) ) > > > > Even if some CPU's have some internal optimization for the case > > where the gate segment is the same as the current one, I wonder if > > it is really important... Interrupts that occur while the processor > > is running userspace already cause changing segments. They are more > > likely to be in cache, maybe. > > there are three main factors: > > - Same-value segment loads are optimized on most modern CPUs and can > give a few cycles (2-3) advantage. That might or might not apply to > the microcode that does IRQ entry processing. (A cache miss will > increase the cost much more but that is true in general as well) > > - A second effect is that the changed data structure layout: a more > compressed GDT entry (6 bytes) against a more spread out (~7 bytes, > not aligned) interrupt trampoline. Note that the first one is data > cache the second one is instruction cache - the two have different > sizes, different implementations and different hit/miss pressures. > Generally the instruction-cache is the more precious resource and we > optimize for that first, for data cache second. > > - A third effect is branch prediction: currently we are fanning > out all the vectors into ~240 branches just to recover a single > constant in essence. That is quite wasteful of instruction cache > resources, because from the logic side it's a data constant, not a > control flow difference. (we demultiplex that number into an > interrupt handler later on, but the CPU has no knowledge of that > relationship) > > ... all in one, the situation is complex enough on the CPU > architecture side for it to really necessiate a measurement in > practice, and that's why i have asked you to do them: the numbers need > to go hand in hand with the patch submission. > > My estimation is that if we do it right, your approach will behave > better on modern CPUs (which is what matters most for such things), > especially on real workloads where there's a considerable > instruction-cache pressure. But it should be measured in any case.
Fully agreed. I will do some measurements in the near future, maybe next week. At least noone came up with an absolutely blocking problem with this approach ;).
Greetings, Alexander
> Ingo -- Alexander van Heukelum heukelum@fastmail.fm
-- http://www.fastmail.fm - IMAP accessible web-mail
| |