On 01/02/2014 10:30 AM, Alexey Perevalov wrote: > From: Anton Vorontsov <[email protected]> > > This patch implements a userland-side API for generic deferrable timers, > per linux/timer.h: > > * A deferrable timer will work normally when the system is busy, but > * will not cause a CPU to come out of idle just to service it; instead, > * the timer will be serviced when the CPU eventually wakes up with a > * subsequent non-deferrable timer. > > These timers are crucial for power saving, i.e. periodic tasks that want > to work in background when the system is under use, but don't want to > cause wakeups themselves. > > The deferred timers are somewhat orthogonal to high-res external timers, > since the deferred timer is tied to the system load, not just to some > external decrementer source. > > So, currently, the implementation has a HZ precision, and the maximum > interval is jiffies resolution (i.e. with HZ=1000, on 32 bit that would > be around max 49 days). Of course we can implement longer timeouts by > rearming the timer, although it probably wouldn't make much sense in > real world, so we keep it simple and just return E2BIG if we don't like > the interval. > > Signed-off-by: Anton Vorontsov <[email protected]> > Signed-off-by: Alexey Perevalov <[email protected]> > --- > fs/timerfd.c | 59 > ++++++++++++++++++++++++++++++++++++++++++--- > include/uapi/linux/time.h | 1 + > 2 files changed, 56 insertions(+), 4 deletions(-) > > diff --git a/fs/timerfd.c b/fs/timerfd.c > index 3561ce7..331ce4b 100644 > --- a/fs/timerfd.c > +++ b/fs/timerfd.c > @@ -30,6 +30,7 @@ struct timerfd_ctx { > union { > struct hrtimer tmr; > struct alarm alarm; > + struct timer_list dtmr; > } t; > ktime_t tintv; > ktime_t moffs; > @@ -51,6 +52,11 @@ static inline bool isalarm(struct timerfd_ctx *ctx) > ctx->clockid == CLOCK_BOOTTIME_ALARM; > } > > +static inline bool isdeferrable(struct timerfd_ctx *ctx) > +{ > + return ctx->clockid == CLOCK_DEFERRABLE; > +} > + > /* > * This gets called when the timer event triggers. We set the "expired" > * flag, but we do not re-arm the timer (in case it's necessary, [snip] > diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h > index e75e1b6..3481cb3 100644 > --- a/include/uapi/linux/time.h > +++ b/include/uapi/linux/time.h > @@ -56,6 +56,7 @@ struct itimerval { > #define CLOCK_BOOTTIME_ALARM 9 > #define CLOCK_SGI_CYCLE 10 /* Hardware specific */ > #define CLOCK_TAI 11 > +#define CLOCK_DEFERRABLE 12 > > #define MAX_CLOCKS 16 > #define CLOCKS_MASK (CLOCK_REALTIME | CLOCK_MONOTONIC)
So, I'm a bit concerned about the CLOCK_DEFERRABLE clockid, as it isn't clear what time domain it uses. Its unlikely to be its own time domain, so this is really a misuse of extending the clockids. It seems to me that deferrability is an attribute of the time domain. So instead of having a CLOCK_DEFERRABLE, I suspect we'll want something like CLOCK_MONOTONIC_DEFER/CLOCK_REALTIME_DEFER, etc. That is, unless we extend the timerfd interface to also take something like a properties flag or something. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
