On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Denys Vlasenko <dvlas...@redhat.com> wrote: > >> PER_CPU_VAR(kernel_stack) was set up in a way where it >> points five stack slots below the top of stack. >> >> Presumably, it was done to avoid one "sub $5*8,%rsp" in >> syscall/sysenter code paths, where iret frame needs to be >> created by hand. >> >> Ironically, none of them benefit from this optimization, >> since all of them need to allocate additional data on >> stack (struct pt_regs), so they still have to perform >> subtraction. > > Well, the original idea of percpu::kernel_stack was that of > an optimization of the 64-bit system_call() path: to set up > RSP as it has to be before we call into system calls. > > This optimization has bitrotted away: because these days > the first SAVE_ARGS in the 64-bit entry path modifies RSP > as well, undoing the optimization.
Yes, I figured this is how it was supposed to work. > But the fix should be to not touch RSP in SAVE_ARGS, to > keep percpu::kernel_stack as an optimized entry point - > with KERNEL_STACK_OFFSET pointing to. > > So NAK - this should be fixed for real. IOW, the proposal is to set KERNEL_STACK_OFFSET to SIZEOF_PTREGS. I can do that. However. There is an ortogonal idea we were discussing: to save registers and construct iret frame using PUSH insns, not MOVs. IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller, but might get slower (at least on some CPUs). If we go that way, we will require KERNEL_STACK_OFFSET = 0 (IOW: the current patch). The decision on how exactly we should fix KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to zero) depends on whether we switch to using PUSHes, or not. What do you think? -- vda -- 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/
