> moon:~/fastcall> ./fastcall
> (INT $0x80 based getpid(), got pid 900) latency:296 cycles
> (SYSENTER based getpid(), got pid 900) latency:126 cycles
>
> so the null-syscall latency speedup is ~135%!
Try it also the other way around, to be sure you are cache hot.
> suggestion: since we can control all the fastcall stubs on the glibc side,
> i'd like to implement a different approach for 5 and 6-parameter system
> calls. Only a minority of system calls has so many arguments, and those
> can take some overhead anyway (since they are complex, obviously). The
> solution would be to wrap all >4 parameter system calls into a special
> 4-parameter setup, where the 4th parameter points to an on-stack array of
> 2 or 3 additional parameters, which would be fetched (in a safe manner) by
> arch/i386 and the generic system calls would be called with 5 or 6
> parameters. This would speed up fast system calls by an additional
> 5%.
What about just forcing >4 parameter system calls to use int80,
collect that 5% speedup and not care about that slow cases?
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- 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/