[Libevent-users] announcing libev, towards a faster and more
featureful libevent
Scott Lamb
slamb at slamb.org
Mon Nov 5 00:54:30 EST 2007
Marc Lehmann wrote:
> On Sun, Nov 04, 2007 at 04:09:08PM -0800, Scott Lamb <slamb at slamb.org> 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.
More information about the Libevent-users
mailing list