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

2014-02-18 Thread Alexey Perevalov
On 02/19/2014 02:33 AM, Thomas Gleixner wrote: On Tue, 18 Feb 2014, Alexey Perevalov wrote: On 02/16/2014 07:39 PM, Thomas Gleixner wrote: I figured out with deviation, I described before. Which is wrong to begin with. Using the wrong method does not justify the results. Are you actually trying

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

2014-02-18 Thread Thomas Gleixner
On Tue, 18 Feb 2014, Alexey Perevalov wrote: > On 02/16/2014 07:39 PM, Thomas Gleixner wrote: > I figured out with deviation, I described before. Which is wrong to begin with. Using the wrong method does not justify the results. Are you actually trying to understand what I'm saying? > It was due

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

2014-02-18 Thread Alexey Perevalov
On 02/16/2014 07:39 PM, Thomas Gleixner wrote: On Sun, 16 Feb 2014, Alexey Perevalov wrote: As I understand main idea in hrtimer.c was do not decrement expires_next in case of DEFERRABLE timers type. Such small average delay could be explained: it's due higher resolution, and cpu is not in idle

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

2014-02-18 Thread Thomas Gleixner
On Mon, 17 Feb 2014, Alexey Perevalov wrote: > On 02/16/2014 07:39 PM, Thomas Gleixner wrote: > Here is the summary: > > now value| difference with previous value > 2159122612405| > 2158816038362|306574043 > 2158532090801|283947561 > 2158200013165|332077636 > 2157928085502|27

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

2014-02-17 Thread Alexey Perevalov
On 02/16/2014 07:39 PM, Thomas Gleixner wrote: On Sun, 16 Feb 2014, Alexey Perevalov wrote: As I understand main idea in hrtimer.c was do not decrement expires_next in case of DEFERRABLE timers type. Such small average delay could be explained: it's due higher resolution, and cpu is not in idle

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

2014-02-16 Thread Thomas Gleixner
On Sun, 16 Feb 2014, Alexey Perevalov wrote: > As I understand main idea in hrtimer.c was do not decrement expires_next in > case of DEFERRABLE timers type. > Such small average delay could be explained: it's due higher resolution, and > cpu is not in idle when we in hrtimer_interrupt, > with timer

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

2014-02-16 Thread Alexey Perevalov
On 02/07/2014 12:50 AM, Thomas Gleixner wrote: On Thu, 6 Feb 2014, Alexey Perevalov wrote: On 02/06/2014 02:16 AM, Thomas Gleixner wrote: 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. NO, NO, NO, NO. Th

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

2014-02-07 Thread Alexey Perevalov
On 02/07/2014 12:50 AM, Thomas Gleixner wrote: On Thu, 6 Feb 2014, Alexey Perevalov wrote: On 02/06/2014 02:16 AM, Thomas Gleixner wrote: 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. NO, NO, NO, NO. Th

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

2014-02-06 Thread Thomas Gleixner
On Thu, 6 Feb 2014, Alexey Perevalov wrote: > On 02/06/2014 02:16 AM, Thomas Gleixner wrote: > 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. NO, NO, NO, NO. There is no mix of timer_list and hrtimer. Eit

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

2014-02-06 Thread John Stultz
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 >>>

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

2014-02-06 Thread Alexey Perevalov
On 02/06/2014 02:16 AM, Thomas Gleixner wrote: On Wed, 5 Feb 2014, John Stultz wrote: On 02/05/2014 01:41 PM, Thomas Gleixner wrote: On Wed, 5 Feb 2014, Alexey Perevalov wrote: On 02/04/2014 08:10 PM, Thomas Gleixner wrote: On Mon, 27 Jan 2014, Alexey Perevalov wrote: On 01/21/2014 11:12 PM,

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

2014-02-05 Thread Thomas Gleixner
On Wed, 5 Feb 2014, John Stultz wrote: > On 02/05/2014 01:41 PM, Thomas Gleixner wrote: > > On Wed, 5 Feb 2014, Alexey Perevalov wrote: > >> On 02/04/2014 08:10 PM, Thomas Gleixner wrote: > >>> On Mon, 27 Jan 2014, Alexey Perevalov wrote: > On 01/21/2014 11:12 PM, John Stultz wrote: > > Th

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

2014-02-05 Thread John Stultz
On 02/05/2014 01:41 PM, Thomas Gleixner wrote: > On Wed, 5 Feb 2014, Alexey Perevalov wrote: >> On 02/04/2014 08:10 PM, Thomas Gleixner wrote: >>> On Mon, 27 Jan 2014, Alexey Perevalov wrote: On 01/21/2014 11:12 PM, John Stultz wrote: > Thomas: Any thought here? Should we be trying to unif

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

2014-02-05 Thread Thomas Gleixner
On Wed, 5 Feb 2014, Alexey Perevalov wrote: > On 02/04/2014 08:10 PM, Thomas Gleixner wrote: > > On Mon, 27 Jan 2014, Alexey Perevalov wrote: > > > On 01/21/2014 11:12 PM, John Stultz wrote: > > > > Thomas: Any thought here? Should we be trying to unify the timerfd flags > > > > and the posix timer

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

2014-02-04 Thread Alexey Perevalov
On 02/04/2014 08:10 PM, Thomas Gleixner wrote: On Mon, 27 Jan 2014, Alexey Perevalov wrote: On 01/21/2014 11:12 PM, John Stultz wrote: Thomas: Any thought here? Should we be trying to unify the timerfd flags and the posix timer flags (specifically things like TIMER_CANCEL_ON_SET, which is curre

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

2014-02-04 Thread Thomas Gleixner
On Mon, 27 Jan 2014, Alexey Perevalov wrote: > On 01/21/2014 11:12 PM, John Stultz wrote: > > > > Thomas: Any thought here? Should we be trying to unify the timerfd flags > > and the posix timer flags (specifically things like TIMER_CANCEL_ON_SET, > > which is currently timerfd-only)? Should a de

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

2014-02-03 Thread John Stultz
On 02/02/2014 10:54 PM, Alexey Perevalov wrote: > Dear John, hello > > could we figure out without Thomas advice? > Maybe it worth to propose timerfd and posix timer flag unification patch? That would likely get his attention (and possibly wrath)... so not a bad idea! ;) thanks -john -- To u

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

2014-02-02 Thread Alexey Perevalov
Dear John, hello could we figure out without Thomas advice? Maybe it worth to propose timerfd and posix timer flag unification patch? On 01/21/2014 11:12 PM, John Stultz wrote: On 01/13/2014 02:43 AM, Alexey Perevalov wrote: Hello dear community. This is reworked patch set of original Anton's

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

2014-01-26 Thread Alexey Perevalov
Dear Thomas, could you please comment John's question (see bellow) regarding flags. On 01/21/2014 11:12 PM, John Stultz wrote: On 01/13/2014 02:43 AM, Alexey Perevalov wrote: Hello dear community. This is reworked patch set of original Anton's Vorontsov proposal regarding unified deferrable ti

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

2014-01-21 Thread John Stultz
On 01/13/2014 02:43 AM, Alexey Perevalov wrote: > Hello dear community. > > This is reworked patch set of original Anton's Vorontsov > proposal regarding unified deferrable timers in the user space. > http://lwn.net/Articles/514707/ > > > I decided to resubmit it due we found it usefull for us too.

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

2014-01-13 Thread Alexey Perevalov
On 01/13/2014 09:36 PM, Andi Kleen wrote: Alexey Perevalov writes: Hello all, one remark - timerfd is not documented in linux Documentation directory at all. I think it's better to have such description. The documentation is the manpage in man-pages. Ideally you change would come with the c

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

2014-01-13 Thread Andi Kleen
Alexey Perevalov writes: > Hello all, > > one remark - timerfd is not documented in linux Documentation > directory at all. > I think it's better to have such description. The documentation is the manpage in man-pages. Ideally you change would come with the changed manpage too. -Andi -- a...

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

2014-01-13 Thread Alexey Perevalov
Hello all, one remark - timerfd is not documented in linux Documentation directory at all. I think it's better to have such description. On 01/13/2014 02:43 PM, Alexey Perevalov wrote: Hello dear community. This is reworked patch set of original Anton's Vorontsov proposal regarding unified

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

2014-01-13 Thread Alexey Perevalov
Hello dear community. This is reworked patch set of original Anton's Vorontsov proposal regarding unified deferrable timers in the user space. http://lwn.net/Articles/514707/ I decided to resubmit it due we found it usefull for us too. timerfd was modified since Anton's commit, Alarm support wa