> > so the null-syscall latency speedup is ~135%!
>
> Try it also the other way around, to be sure you are cache hot.
yep, the testcode ensures that it's cache-hot. With the latest patch the
getpid() speed is 142 cycles, which is still a ~120% speedup.
> What about just forcing >4 parameter system calls to use int80,
> collect that 5% speedup and not care about that slow cases?
well, if we can make mmap() and select() faster without slowing down other
system calls then why not? I've implemented the 'dual syscall table' thing
and it works out well. The method is that for mmap() there is a
_different_ entry in fastsys_call_table[]: sys_mmap2_4arg(), which does:
asmlinkage long sys_mmap2_4arg(unsigned long addr, unsigned long len,
unsigned long prot, unsigned long * userstack)
{
int err;
unsigned long flags;
unsigned long fd;
unsigned long pgoff;
if (verify_area(VERIFY_READ, userstack, 3*sizeof(long)))
return -EFAULT;
err = 0;
err |= __get_user(flags, userstack++);
err |= __get_user(fd, userstack++);
err |= __get_user(pgoff, userstack);
if (err)
return -EFAULT;
return do_mmap2(addr, len, prot, flags, fd, pgoff);
}
with this method we can wrap arbitrary number of arguments into the
4-parameter syscall interface, without slowing down the majority of system
calls. (there are only 6 syscalls which have 5 or 6 parameters, and only
select() and mmap() are the ones that are also performance-critical.)
this is still faster than 100 cycles, especially given the fact that even
int $80 mmap() already goes through a trampoline.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/