On Tue, 4 Mar 2014, Andy Lutomirski wrote: > On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner <t...@linutronix.de> wrote: > > On Tue, 25 Feb 2014, Andy Lutomirski wrote: > >> On the other hand, if you added a fancier version of timerfd_settime > >> that could explicitly set the slack value (or, equivalently, the > >> earliest and latest allowable times), that could be quite useful. > >> > >> It's often bugged me that timer slack is per-process. > > > > That's a totally different issue. There is a world aside of timerfd > > timers. > > This is a patch to add deferrable support *to timerfd*. I'm asking
There is a new patch series which adds deferrable support to all timer related interfaces which have a flags field. And that's the only sensible solution right now. We do no add another random special case syscall for timerfd just because timerfd is linux specific. No, we want to support that stuff right now with the existing interfaces as we have to revisit all of the timer related interfaces in the near future anyway due to the Y2038 issue. And your idea of per thread slack is completely bogus. If we want to make the slack value usefull then it needs to be done per timer and not per thread/process. But we cannot do that right now as we cannot whip up severl dozen of new syscalls just because we want to add slack/deferrable whatever properties. Once we agree on a solution to the Y2038 issue on 32bit with a unified 32/64 bit syscall interface which simply gets rid of the timespec/val nonsense and takes a simple u64 nsec value we can add the slack property to that without any further inconvenience. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/