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

[John Stultz]

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?
>>
>> thanks
>> -john
>>
>>
>
> 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
> level.
>
> 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).

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
clockids (ie: CLOCK_BOOTTIME_DEFERRED, CLOCK_TAI_DEFERRED,
CLOCK_REALTIME_DEFERRED).


>
> 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?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/