Messages in this thread | | | From | "Alexander van Heukelum" <> | Subject | Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes | Date | Tue, 04 Nov 2008 19:44:16 +0100 |
| |
On Tue, 04 Nov 2008 10:14:11 -0800, "H. Peter Anvin" <hpa@zytor.com> said: > Alexander van Heukelum wrote: > > > > That's good to know. I assume this LOCKed bus cycle only occurs > > if the (hidden) segment information is not cached in some way? > > How many segments are typically cached? In particular, does it > > optimize switching between two segments? > > > > Yes, there is a segment descriptor cache (as opposed to the hidden but > architectural segment descriptor *registers*, which the Intel > documentation confusingly call a "cache".) > > It is used to optimize switching between a small number of segments, and > was crucial for decent performance on Win9x, which contained a bunch of > 16-bit code.
Thanks for the info!
This just means that if there are performance problems, the 'specialized' handlers should be using the kernel segment or maybe a single common segment. It would still allow us to get rid of the trampolines. A stack trace should be enough to reconstruct which vector was originally called in that case. Only the common_interrupt-codepath needs the original vector as far as I can see.
You just made testing on larger machines with a lot of external interrupts necessary :-/. (Assuming small machines do not show performance problems, that is.)
Greetings, Alexander
> -hpa -- Alexander van Heukelum heukelum@fastmail.fm
-- http://www.fastmail.fm - I mean, what is it about a decent email service?
| |