On Wed, Feb 25, 2015 at 3:43 PM, Steven Rostedt <rost...@goodmis.org> wrote: > On Wed, 25 Feb 2015 10:20:43 +0100 Ingo Molnar <mi...@kernel.org> wrote: >> But, if we do that, we can do even better, and also do an >> optimization of the 64-bit entry path as well: we could >> simply mask RAX with 0x3ff and not do a compare. Pad the >> syscall table up to 0x400 (1024) entries and fill in the >> table with sys_ni syscall entries. >> >> This is valid on 64-bit and 32-bit kernels as well, and it >> allows the removal of a compare from the syscall entry >> path, at the cost of a couple of kilobytes of unused >> syscall table. >> >> The downside would be that if we ever grow past 1024 >> syscall entries we'll be in trouble if new userspace calls >> syscall 513 on an old kernel and gets syscall 1. > > What if we test against ~0x3ff and jump to sys_ni if anything is set. > This would still work with new userspace calls on older kernels.
That would require a branch insn. The whole idea of masking was merely to avoid that branch. If you need a branch, then you can as well just retain current code. -- 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/
