1. 24
  1.  

  2. 4

    I really think that maybe the solution here is to have software that does not need to focus on its need to make 500m syscalls (the actual call is irrelevant) a minute.

    If 40s of systime kills you, the 10s in userspace is also likely to be hurt ing. Looking at the CPU time ratios makes it easy to miss the point…if this is impacting you the problem is your code, not your hosting provider who is X% slower for the $foobar syscall.

    This kind of research is only useful for those running the host, not the guest, as for userspace the solution is just to reduce the number of syscalls made. For the host though, they would be able to reclaim CPU time and allocate that back to guests.

    Problem is, if these workloads are normal, or things that are major problems for you as a hosting provider, you either are overcontending your guests, but then those guests are not spinning on gettimeofday() anyway, or…nope that’s the only thing I can think of.

    Maybe someone has been getting a little too excited about all the recent ZOMGBBQsyscallBLOGZ posts that seem to be making the rounds.

    With my sysadmin hat on, I wish people just put out rule of thumb guidelines for developers on how to use strace/ltrace and how to interpret its output; syscalls to wall clock time and work output and not silly microoptimisations to distract you from ‘you really need to solve this problem so we can make payroll this month’.

    syscall’s are not bad persay, they enable you to do other things sometimes too…

    1. 1

      Interesting research, although I’m pretty sure that saying A is 77% faster than B does not mean B is 77% slower than A.