a lot of clock_gettime syscalls

[Marc Lehmann]

On Wed, Nov 06, 2013 at 06:38:55PM +0400, Roman Strashkin <roman.strashkin at gmail.com> wrote:
> Could you help me understand why i have a lot of clock_gettime syscalls.

You have to identify the code that does these. Libev does call
clock_gettime itself, usually once per iteration (at most twice), but does
not itself cause more calls. Anybody can call this function, so you need
to find out where the majority of these calls originate.

> 1. several (4-6) worker-thread (they communicate to main thread via
> ev_async_send(); one per worker-thread)
> 2. one read watcher
> 3. one write watcher
> 4. one check_watcher
> 
> I see that system spends ~10 % of app-work-time.

libev can only create a lot of clock_gettime calls if your app is not
doing any other work. That is, when you do almost nothing per iteration
and poll for events a lot, then you might get a lot of clock_gettime
calls, as libev needs to find out how much time has passed.

> Is it possible to optimize that ?

Sure, switch to GNU/Linux - on typical server hardware (and a modenr
enough glibc), clock_gettime is entirely handled in userspace there, and
quite fast as well :)

You can also consider using ev_set_io_collect_interval or
ev_set_timeout_collect_interval. These "simulate" a higher workload and will
reduce the number of iterations per time.

For example, ev_set_io_collect_interval (loop, 1) would result in libev
sleeping a second before polling for new events. Thats an extra syscall per
iteration, but reduces the iteraitons to at most one per second.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\