Marc Lehmann wrote:
> On Sun, Nov 04, 2007 at 04:09:08PM -0800, Scott Lamb <[EMAIL PROTECTED]> 
> wrote:
>> Have you seen the new Linux timerfd API? Where available, you can wait
>> for CLOCK_MONOTONIC and CLOCK_REALTIME events independently. Beats
>> heuristics,
> How? I still need to detect time jumps. If my ev_periodic is to be scheduled
> every minute, on the minute, and somebody resets the time the timer needs to
> be rescheduled. With timerfd I would need to detetc that and remove/insert
> the timer again.

My impression was you could create such a timer like this:

    struct itimerspec it = {
        .it_value    = { .tv_sec = 0,  .tv_nsec = 0 },
        .it_interval = { .tv_sec = 60, .tv_nsec = 0 },

    sts = timerfd(my_timerfd, CLOCK_REALTIME, TFD_TIMER_ABSTIME, &it);

and any adjustments are the kernel's responsibility. It is aware of the
adjtime() calls and such as they happen.

I have not tested this myself.

> (You might have no use for periodics for timeouts, but they are designed
> to solve this very problem :)
> Besides, having a syscall per timer (or even timer change) would be an
> enourmous overhead for many workloads.

Really? Syscalls aren't really *that* expensive in and of themselves,
and it'd be a rare application that makes an order of magnitude more
timerfd() calls than read()/write() calls.

>> and detecting time jumps sound like introducing a lot of extra
>> timeouts.
> I don't quite see how that would happen with either timer event currently in
> libev, unless the user code forces it.
>> I'd hate to see libev(ent)? show up on PowerTOP after just getting rid
>> of the 5-second timeout.
> Now idea what powertop is, but sporiadic servers might use a lot of cpu
> without the kernel ever realising it :)

PowerTOP is a Linux tool for seeing the top causes of timeouts. Recently
people are trying to make better use of processor idle states, so it's
important to not fire timeouts unnecessarily.
Libevent-users mailing list

Reply via email to