Messages in this thread | | | Date | Thu, 06 Feb 2014 09:47:14 -0800 | From | John Stultz <> | Subject | Re: [PATCH v2 0/3] Deferrable timers support for timerfd API |
| |
On 02/06/2014 09:38 AM, Alexey Perevalov wrote: > On 02/06/2014 02:16 AM, Thomas Gleixner wrote: >> On Wed, 5 Feb 2014, John Stultz wrote: >>> My reasoning was that the deferrablity isn't a clock domain, and is >>> more >>> of a modifier. Thus to keep the interfaces somewhat sane (and avoiding >>> having to add N new clockids for each new modifier), we should utilize >>> the flag arguments to timers. So instead of just having TIMER_ABSTIME, >>> we could add TIMER_DEFER, etc, which we could utilize instead. >> I can see the point. I have no objections against that approach as >> long as we map that against separate internal bases. >> >>> Internally we can still keep separate bases, much as your patch >>> does, to >>> keep the next-event searching overhead more limited. >> It's not only more limited, it's bound. >> >>> I mainly wanted to get your thoughts on extending the flags, and doing >>> so in a consistent manner between the timerfd and other timer >>> interfaces. >> So the only interface which does not support that is sys_nanosleep() >> but that's not really an issue. sys_nanosleep() should die anyway :) >> >>> Of course, all this is after I added the _ALARM clockids... so you can >>> decide if its hypocrisy or experience. >>> (The "old wisdom comes from experience and experience comes from bad >>> decisions" bit ;). >> Well, you have a valid point about the clock ids. I did not realize in >> the first place that we can avoid that business if we use the flags to >> select the internal representation. >> >> Either way is preferred over reintroducing the timer wheel mess.... > > As I truly understand, you decided - flags is better than new > clockids, and internals of timerfd could be a mix of timer_list and > hrtimer. > If so, it's in v2 patch set.
So, I think Thomas is suggesting we add new deferrable HRTIMER bases, then the timerfd code would only use the hrtimers for non-alarm-timers. We would then use the flag from the interface to decide internally which base to add the hrtimer to. This would also allow us to use the flag via non-timerfd interfaces to get the same result.
Does that clarify things?
thanks -john
| |