Re: [PATCH/RFC] Move entry_64.S register saving out of the macros

From: H. Peter Anvin
Date: Wed Nov 19 2008 - 12:56:19 EST


Alexander van Heukelum wrote:
Hi all,

Here is a combined patch that moves "save_args" out-of-line for
the interrupt macro and moves "error_entry" mostly out-of-line
for the zeroentry and errorentry macros.

The save_args function becomes really straightforward and easy
to understand, with the possible exception of the stack switch
code, which now needs to copy the return address of to the
calling function. Normal interrupts arrive with ((~vector)-0x80)
on the stack, which gets adjusted in common_interrupt:

<common_interrupt>:
(5) addq $0xffffffffffffff80,(%rsp) /* -> ~(vector) */
(4) sub $0x50,%rsp /* space for registers */
(5) callq ffffffff80211290 <save_args>
(5) callq ffffffff80214290 <do_IRQ>
<ret_from_intr>:
...

An apic interrupt stub now look like this:

<thermal_interrupt>:
(5) pushq $0xffffffffffffff05 /* ~(vector) */
(4) sub $0x50,%rsp /* space for registers */
(5) callq ffffffff80211290 <save_args>
(5) callq ffffffff80212b8f <smp_thermal_interrupt>
(5) jmpq ffffffff80211f93 <ret_from_intr>


Sorry, I'm away on a trip at the moment, so sorry for the delayed feedback.

First of all, if we're going to go through common code here, we should do the vector number adjustment in save_args and be able to use the short form of pushq in the common case.

What isn't clear to me is if we should just push a target field to the stack and then do an indirect call. That way we can do save_args and ret_from_intr inline, but at the expense of an indirect call which will not necessarily speculate cleanly.

All of this qualify as "tweaking", which means we need to be very careful so we don't end up burning more performance than we gain, but all in all, I think this is a good idea.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/