* Andy Lutomirski <l...@kernel.org> wrote:
> This is separate for ease of bisection.
>
> Signed-off-by: Andy Lutomirski <l...@kernel.org>
> ---
> arch/x86/entry/entry_64.S | 68
> +++++------------------------------------------
> 1 file changed, 7 insertions(+), 61 deletions(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 33acc3dcc281..a5044d7a9d43 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -229,6 +229,11 @@ entry_SYSCALL_64_fastpath:
> */
> USERGS_SYSRET64
>
> +GLOBAL(int_ret_from_sys_call_irqs_off)
> + TRACE_IRQS_ON
> + ENABLE_INTERRUPTS(CLBR_NONE)
> + jmp int_ret_from_sys_call
Any reason why irq state tracking cannot be done in C as well, like the rest of
the irq state tracking code?
(Btw., context tracking could in theory be merged with irq state tracking, they
have similar needs.)
One complication would be that we have not saved pt_regs yet:
> @@ -272,69 +277,10 @@ tracesys_phase2:
> * Has correct iret frame.
> */
> GLOBAL(int_ret_from_sys_call)
> SAVE_EXTRA_REGS
> + movq %rsp, %rdi
> + call syscall_return_slowpath /* returns with IRQs disabled */
> RESTORE_EXTRA_REGS
... but we can stipulate that IRQs can be enabled after we've constructed
pt_regs.
The few cycles constant added latency there isn't an issue - maintainability of
the code is.
... this would also allow us to get rid of paravirt interface uglies like
'CLBR_NONE' which has no place in generic entry code.
With such a conversion very little 'high level, complex logic' should be left
in
assembly and as much as possible should be moved to C: that way we can
integrate
it all on the C level and achieve similar speedups as with assembly. Half-done
will reduce that potential of speedups through integration.
A bit like how we have done it with do_page_fault(): there's very little left
at
the assembly level, still it has not kept people from micro-optimizing the heck
out of the low level page fault code.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
