Messages in this thread | | | Date | Sun, 05 Jan 2014 23:33:48 +0400 | From | Alexey Perevalov <> | Subject | Re: [PATCH 0/3] Deferrable timers support for timerfd API |
| |
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? >>> >>> 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). 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 > clockids (ie: CLOCK_BOOTTIME_DEFERRED, CLOCK_TAI_DEFERRED, > CLOCK_REALTIME_DEFERRED). > 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.
> > thanks > -john > >
-- Best regards, Alexey Perevalov
| |