Suggestions on Avoiding syscall Overhead

Robert Watson rwatson at
Mon Apr 23 19:42:30 UTC 2007

On Tue, 24 Apr 2007, Peter Jeremy wrote:

> I do not believe that these syscalls are called frequently enough that 
> improving their efficiency will be measurable anywhere other than 
> microbenchmarks that specifically measure their speed.  I had a quick look 
> through syscall.h and didn't see any syscalls that were both used often and 
> were amenable to this approach.
> Before spending much efford on implementing this shared-page approach, I 
> would suggest that you instrument syscall() to count the number of syscalls 
> by type see if any heavily used syscalls can be implemented using this 
> approach.
> The comment was made elsewhere "if it's easy to do, do it anyway, even if 
> there's no measurable benefit".  I would strongly disagree with this 
> comment.  Any code that is added to FreeBSD requires ongoing effort to 
> maintain it - even if it's just waiting longer for the system to compile. 
> Special casing some system calls means that those system calls need special 
> regression tests to ensure that they haven't been broken somehow.  Unless 
> there is some benefit, then don't bother making the change.
> FreeBSD does appear to have higher syscall overheads than (eg) Linux. The 
> best solution is to work on reducing this overhead in general (trap handling 
> and syscall(), rather than identifying a small subset of syscalls and 
> bypassing the syscall overhead for them.

Profiling should definitely be the first step in any project along these lines 
-- we know from some past informal profiling that important workloads such as 
pgsql and mysql do hammer unexpected system calls (sysctl, time queries), and 
that these are likely points for optimization, but at the very least we need 
this confirmed in a reproduceable environment so we can trade off optimization 
techniques and see which provide the best result.  The list of tools -- faster 
system call paths, VM and page tricks, etc, are all reasonable ways to 
approach the problem once it's well-characterized.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-current mailing list