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

[Alexey Perevalov]

On 01/10/2014 12:32 AM, John Stultz wrote:
> On Sun, Jan 5, 2014 at 11:33 AM, Alexey Perevalov
> <a.perevalov@xxxxxxxxxxx> wrote:
> > On 01/04/2014 04:18 AM, John Stultz wrote:
> > > 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?
> Well, my first reaction was just to suggest you create a new timer
> flag (like TIMER_ABSTIME) TIMER_DEFER, which we could then consider
> adapting as a new flag value for all the timer related code
> (posix-timers, nanosleep, etc).
>
> Then looking closer at the timerfd code, I see I wasn't aware there's
> some additional constraints as the timerfd flags overlap with many of
> the file O_ flags, and that the timerfd has its own TFD_TIMER_ABSTIME.
>   I'm not quite sure I recall the context of that decision, so it might
> be good to involve those who recall more of that history. So I'm not
> sure which particular bit flag would be best to take there. Anton's
> patch took (1<<2), so I'm guessing that's still ok.
>
> Anyway, adding something like a TFD_TIMER_DEFER along with TIMER_DEFER
> would seem to me like a reasonable approach.
>
> Addtionally the TFD_CANCEL_ON_SET is interesting in that we don't have
> a similar flag for the posix timers interfaces. Do you think there's
> any value in looking into unifying that as well?
Posix timer doens't have cancel_list ability right now.
Do you want to add such ability?
With posix timer there is no problem of interference O_ flags,
and flag for posix timer might have the same value as 
TFD_TIMER_CANCEL_ON_SET,
and appropriate name.

Version of Anton's patches with flag based interface I'll send tomorrow.
But with little modification in overruns, I think evaluation
based on hrtimer for overrun is not proper way for deferrable timer, because
in most cases number of deferrable ticks is lesser.

> thanks
> -john


--
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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/