Re: [PATCH 0/3] Deferrable timers support for timerfd API

From: Alexey Perevalov
Date: Sun Jan 05 2014 - 14:34:30 EST

On 01/04/2014 04:18 AM, John Stultz wrote:
On 01/03/2014 09:45 AM, Alexey Perevalov wrote:
On 01/03/2014 03:17 AM, John Stultz wrote:
On 01/02/2014 10:30 AM, Alexey Perevalov wrote:
This version introduces new clockid (CLOCK_DEFERRABLE) , for
timerfd_create, instead of
new flag (TFD_TIMER_DEFERRABLE) for timerfd_settime introduced in
previous version.
So why did you make this change?


I looked at alarm timers and found approach of making timer behavior
persistent per file descriptor is better than
changeable by timerfd_settime. I think "end user wake up from suspend"
and "don't wake up in idle" is the same thing on the same abstraction

Yes Anton's previous patches worked with CLOCK_MONOTONIC only and I
didn't intend to use it with CLOCK_REALTIME, cause it's hard to me to
find such use case.
Another way - it's stay as was Anton's patch, I mean as flag for the
timerfd_settime, but in original patch set both hrtimer and deferrable
timers initialized in timerfd_create, I think it's not needed. Also
ability to change timer behavior looks not good if you couldn't change
alarm timer behavior, not unified API.
So while the alarm timers are a reasonable precedent, I think they were
introduced prior to the timerfd interface, so it seemed at the time
having new clockids for the functionality was required to work with the
existing syscalls that use the clockid (Though in retrospect, I question
if it would have been better to use timer flags to introduce the alarm
functionality rather then introducing it via a clockid, as it would
simplify the clockid definitions).
As I understood alarm and deferrability it's type of repetition (timer trigger condition),
but REALTIME, BOOTTIME, MONOTONIC it's a type of time representation.
Mixed it in one clockid, maybe it's a controversially. Which flags do you want to use, flags of timerfd_settime?

Now that we have the timerfd interface, and if this functionality is
really limited to the timerfds, then we may want to consider what might
be, at least to me, the cleaner approach of using the flag.

Either way, I'd like to make sure we have a sound rational. My worry is
that deferrable timers would be desired on more then just
CLOCK_MONOTONIC, so we could quite likely end up with quite a few new

Here I'm totally agree CLOCK_DEFERRABLE is not maintainable named constant.

If I'm right, only high resolution timer could be REALTIME, and there
is no deferrable behavior for hrtimer only for timer_list.

I'm not sure I understood this part. Could you explain further?
I meant, we couldn't use hrtimer for deferrability, right now.


Best regards,
Alexey Perevalov
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at