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 CambridgeReceived on Mon Apr 23 2007 - 17:42:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:09 UTC