[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXy3ft8AipAm=_u9OJb-t+FF=AfvXBke4pTh5a25nTcFA@mail.gmail.com>
Date: Tue, 1 Jul 2014 13:18:38 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Kees Cook <keescook@...omium.org>,
Will Drewry <wad@...omium.org>
Subject: Seccomp performance vs. asm complexity
This is a question about tradeoffs. I'm playing with a couple of
approaches for an x86 seccomp fast path.
It looks like populating struct seccomp_data in the syscall entry asm
code saves 4-5ns (83ns vs 87.7ns or so for getpid with seccomp
enabled). Presumably this is because it avoids a branch and replaces
seven two-instruction memory copies with 6 register pushes and one
memory push. It also keeps the code shorter, with corresponding
icache benefits.
OTOH, populating struct seccomp_data in C keeps the asm code shorter
and simpler. In fast, it ends up being a net deletion of asm code.
Thoughts? What's a line of assembly code worth? Keep in mind that
someone will probably want to port this to the x86_32 and compat
entries.
To keep this in perspective, this is down from >200ns in 3.16-rc3.
My current code is here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/seccomp-fastpath
I think it's in pretty good shape, but I still want to play with it a
bit before sending it out. This version uses the C approach.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists