Ingo Molnar wrote:
.. 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).
I'm not unconvicable, but we need to be conservative here: could you
try to measure the full before/after cost of IRQ entry, to the cycle
level? I'm curious what the performance impact is.
Also, this makes life probably a bit harder for Xen, which assumes
that the GDT of the guest OS is small-ish. (Jeremy Cc:-ed)
It doesn't increase the GDT to more than one page, so there's no issue
there. The only reason the GDT uses a whole page is because of Xen's
requirements anyway, so if we can make good use of the rest of the
entries, so much the better.
The other possible concern with Xen is whether Xen will properly load an
arbitrary %cs on exception entry, or if it always loads KERNEL_CS; looks
like it will load any %cs, so we should be fine there.
Overall the patch looks good. Saving a segment register should be much
faster than loading it, so I don't think the %cs read on entry should
cost too much, but reloading %cs with KERNEL_CS might be a bit more of a
cost (or does it run the whole exception with the new %cs?).
J
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
