* Denys Vlasenko <dvlas...@redhat.com> wrote:
> > 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?
Yes.
> A data point. I implemented push-based creation of
> pt_regs and benchmarked it. The patch is on top of all my
> latest patches sent to ML.
>
> On SandyBridge CPU, it does not get slower: seems to be 1
> cycle faster per syscall.
>
> We lose a number of large insns there:
>
> text data bss dec hex filename
> - 9863 0 0 9863 2687 entry_64.o
> + 9671 0 0 9671 25c7 entry_64.o
That's a nice reduction in I$ footprint ...
> + /* Construct struct pt_regs on stack */
> + pushq $__USER_DS /* pt_regs->ss */
> + pushq PER_CPU_VAR(old_rsp) /* pt_regs->sp */
> + pushq %r11 /* pt_regs->flags */
Btw., this could also construct all the dwarf annotations
in a natural, maintainable fashion - pushq_cfi and friends?
> + pushq $__USER_CS /* pt_regs->cs */
> + pushq %rcx /* pt_regs->ip */
> + pushq %rax /* pt_regs->orig_ax */
> + pushq %rdi /* pt_regs->di */
> + pushq %rsi /* pt_regs->si */
> + pushq %rdx /* pt_regs->dx */
> + pushq %rcx /* pt_regs->cx */
> + pushq $-ENOSYS /* pt_regs->ax */
> + pushq %r8 /* pt_regs->r8 */
> + pushq %r9 /* pt_regs->r9 */
> + pushq %r10 /* pt_regs->r10 */
> + sub $(7*8),%rsp /* pt_regs->r11,bp,bx,r12-15 */
So the 'SUB' there is a bit sad, but push sequences are
generally easier to read, so I like it altogether.
Then we could indeed get rid of KERNEL_STACK_OFFSET.
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/
