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

["H. Peter Anvin" <hpa@zytor.com>]

Okay, looking at this some more, the current interrupt stubs are just
plain braindead.

We have a large number of push instructions which save a negative
number, even when that means using the full 5-byte form; then we use:

	unsigned vector = ~regs->orig_ax;

in do_IRQ.  This is utterly moronic; if we use the short form push at
all times, then we can set the upper bits (which distinguish us from a
system call entry) at leisure (via a simple orl in common code), rather
than in each stub, which to boot bloats it above the 8-byte mark.

That way, each stub has the simple form:

	6A xx E9 yy yy yy yy 90

Down to 8 bytes, including one byte of padding.  Already better - we are
down to 2K total, and each stub is aligned.

Now, we can do better than that at the cost of an extra branch.  The
extra branch, however, is a direct unconditional branch and so is not
subject to misprediction (good), although it may end up taking an extra
icache miss (bad):

we can group our vectors in 8 groups of 32 vectors each.  Each contain a
stub of the form:

	6A xx EB yy

... which jump to a common jump instruction at the end of each group.
Thus, each group takes 32*4+5 bytes+3 bytes for alignment = 136 bytes,
for a total of 1088 bytes.

This has two disadvantages:
- an extra jump.
- we can no longer redirect a stub away from common code by
  changing the branch in that slot.  We have to instead modify
  the IDT.  This means "dedicated" interrupts don't get the
  vector number at all, which is probably fine -- to be honest,
  I'm not sure if they do at the moment either.

Fixing the first of these I think is a no-brainer.  That will cut the
size of the existing stub pool by almost half.  The second is more of a
judgement call, and I'd like to see performance numbers for it.  Either
which way, I think it's worthwhile to consider this as an alternative to
  playing segmentation tricks, which I think could have really nasty
side effects.

	-hpa