Re: [RFC/INCOMPLETE 08/13] x86/entry/64: Migrate 64-bit syscalls to new exit hooks

[Ingo Molnar]

* Andy Lutomirski <luto@xxxxxxxxxx> wrote:

> This is separate for ease of bisection.
> 
> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
> ---
>  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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/