Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Pavel Machek
Hi! On Sun 2016-06-26 12:21:46, Arjan van de Ven wrote: > On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > > > Umm. I'm not sure if you should be designing kernel... > > > > I have alarm clock application. It does sleep(60) many times till its > > time to wake me up. I'll

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Pavel Machek
Hi! On Sun 2016-06-26 12:21:46, Arjan van de Ven wrote: > On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > > > Umm. I'm not sure if you should be designing kernel... > > > > I have alarm clock application. It does sleep(60) many times till its > > time to wake me up. I'll be very angry

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Arjan van de Ven
On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > Umm. I'm not sure if you should be designing kernel... > > I have alarm clock application. It does sleep(60) many times till its > time to wake me up. I'll be very angry if sleep(60) takes 65 seconds > without some very, very

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Arjan van de Ven
On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > Umm. I'm not sure if you should be designing kernel... > > I have alarm clock application. It does sleep(60) many times till its > time to wake me up. I'll be very angry if sleep(60) takes 65 seconds > without some very, very good reason.

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Pavel Machek
Hi! > > FWIW, testing with ltp, I noticed a new failure in logs. It turns out > > to be intermittent, but the testcase mostly fails. > > You forgot to cc the LTP folks ... > > > rtbox:~ # > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > Test FAILED:

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-26 Thread Pavel Machek
Hi! > > FWIW, testing with ltp, I noticed a new failure in logs. It turns out > > to be intermittent, but the testcase mostly fails. > > You forgot to cc the LTP folks ... > > > rtbox:~ # > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > Test FAILED:

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > > That is likely POSIX conformance bug, since POSIX explicitly states that > > sigtimedwait() shall use CLOCK_MONOTONIC to measure the timeout. > > > > "If the Monotonic Clock option is supported, the CLOCK_MONOTONIC clock > > shall be used to measure the time interval specified by the

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > > That is likely POSIX conformance bug, since POSIX explicitly states that > > sigtimedwait() shall use CLOCK_MONOTONIC to measure the timeout. > > > > "If the Monotonic Clock option is supported, the CLOCK_MONOTONIC clock > > shall be used to measure the time interval specified by the

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Thu, 23 Jun 2016, Cyril Hrubis wrote: > > 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most > >system call timeouts (including specifically the one in FUTEX_WAIT) > >use the high-resolution timer subsystem, which is a whole different > >animal with tighter

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Thu, 23 Jun 2016, Cyril Hrubis wrote: > > 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most > >system call timeouts (including specifically the one in FUTEX_WAIT) > >use the high-resolution timer subsystem, which is a whole different > >animal with tighter

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > Two points: > 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most >system call timeouts (including specifically the one in FUTEX_WAIT) >use the high-resolution timer subsystem, which is a whole different >animal with tighter guarantees, and That is likely POSIX

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > Two points: > 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most >system call timeouts (including specifically the one in FUTEX_WAIT) >use the high-resolution timer subsystem, which is a whole different >animal with tighter guarantees, and That is likely POSIX

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Thu, 23 Jun 2016, George Spelvin wrote: > Cyril Hrubis wrote: > > Thomas Gleixner wrote: > >> Err. You know that the timer expired because sigtimedwait() returns > >> EAGAIN. And the only thing you can reliably check for is that the timer did > >> not expired to early. Anything else is

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Thu, 23 Jun 2016, George Spelvin wrote: > Cyril Hrubis wrote: > > Thomas Gleixner wrote: > >> Err. You know that the timer expired because sigtimedwait() returns > >> EAGAIN. And the only thing you can reliably check for is that the timer did > >> not expired to early. Anything else is

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread George Spelvin
Cyril Hrubis wrote: > Thomas Gleixner wrote: >> Err. You know that the timer expired because sigtimedwait() returns >> EAGAIN. And the only thing you can reliably check for is that the timer did >> not expired to early. Anything else is guesswork and voodoo programming. > But seriously is there a

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread George Spelvin
Cyril Hrubis wrote: > Thomas Gleixner wrote: >> Err. You know that the timer expired because sigtimedwait() returns >> EAGAIN. And the only thing you can reliably check for is that the timer did >> not expired to early. Anything else is guesswork and voodoo programming. > But seriously is there a

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > > While this is true, checking with reasonable error margin works just > > fine 99% of the time. You cannot really test that timer expires, without > > setting arbitrary margin. > > Err. You know that the timer expired because sigtimedwait() returns > EAGAIN. And the only thing you can

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Cyril Hrubis
Hi! > > While this is true, checking with reasonable error margin works just > > fine 99% of the time. You cannot really test that timer expires, without > > setting arbitrary margin. > > Err. You know that the timer expired because sigtimedwait() returns > EAGAIN. And the only thing you can

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Wed, 22 Jun 2016, Cyril Hrubis wrote: > Hi! > > > rtbox:~ # > > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > > Test FAILED: sigtimedwait() did not return in the required time > > > time_elapsed: 1.197057 > > > ...come on, you can do it... > > > rtbox:~ #

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-23 Thread Thomas Gleixner
On Wed, 22 Jun 2016, Cyril Hrubis wrote: > Hi! > > > rtbox:~ # > > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > > Test FAILED: sigtimedwait() did not return in the required time > > > time_elapsed: 1.197057 > > > ...come on, you can do it... > > > rtbox:~ #

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Wed, 2016-06-22 at 11:06 +0200, Mike Galbraith wrote: > On Wed, 2016-06-22 at 10:44 +0200, Thomas Gleixner wrote: > > B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > > > FWIW, testing with ltp, I noticed a new failure in logs. It turns > > out > > > to be intermittent, but the testcase

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Wed, 2016-06-22 at 11:06 +0200, Mike Galbraith wrote: > On Wed, 2016-06-22 at 10:44 +0200, Thomas Gleixner wrote: > > B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > > > FWIW, testing with ltp, I noticed a new failure in logs. It turns > > out > > > to be intermittent, but the testcase

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Cyril Hrubis
Hi! > > rtbox:~ # > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > Test FAILED: sigtimedwait() did not return in the required time > > time_elapsed: 1.197057 > > ...come on, you can do it... > > rtbox:~ # > >

Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Cyril Hrubis
Hi! > > rtbox:~ # > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test > > Test FAILED: sigtimedwait() did not return in the required time > > time_elapsed: 1.197057 > > ...come on, you can do it... > > rtbox:~ # > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Wed, 2016-06-22 at 10:44 +0200, Thomas Gleixner wrote: > B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > > FWIW, testing with ltp, I noticed a new failure in logs. It turns > out > > to be intermittent, but the testcase mostly fails. > > You forgot to cc the LTP folks ... This ain't

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Wed, 2016-06-22 at 10:44 +0200, Thomas Gleixner wrote: > B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > > FWIW, testing with ltp, I noticed a new failure in logs. It turns > out > > to be intermittent, but the testcase mostly fails. > > You forgot to cc the LTP folks ... This ain't

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Thomas Gleixner
B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > FWIW, testing with ltp, I noticed a new failure in logs. It turns out > to be intermittent, but the testcase mostly fails. You forgot to cc the LTP folks ... > rtbox:~ # >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Thomas Gleixner
B1;2802;0cOn Wed, 22 Jun 2016, Mike Galbraith wrote: > FWIW, testing with ltp, I noticed a new failure in logs. It turns out > to be intermittent, but the testcase mostly fails. You forgot to cc the LTP folks ... > rtbox:~ # >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Fri, 2016-06-17 at 13:26 +, Thomas Gleixner wrote: > This is the second version of the timer wheel rework series. The first series > can be found here: > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de > > The series is also available in git: > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-22 Thread Mike Galbraith
On Fri, 2016-06-17 at 13:26 +, Thomas Gleixner wrote: > This is the second version of the timer wheel rework series. The first series > can be found here: > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de > > The series is also available in git: > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Eric Dumazet
On Mon, Jun 20, 2016 at 12:03 PM, Rik van Riel wrote: > On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >> >> 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a >> 1000HZ >>option so datacenter folks can use this and people who don't care >> and

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Eric Dumazet
On Mon, Jun 20, 2016 at 12:03 PM, Rik van Riel wrote: > On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >> >> 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a >> 1000HZ >>option so datacenter folks can use this and people who don't care >> and want >>better

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Rik van Riel
On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >  > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a > 1000HZ >    option so datacenter folks can use this and people who don't care > and want >    better batching for power can use the 4ms thingy. > It might be

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Rik van Riel
On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >  > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a > 1000HZ >    option so datacenter folks can use this and people who don't care > and want >    better batching for power can use the 4ms thingy. > It might be

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Arjan van de Ven
so is there really an issue? sounds like KISS principle can apply On Mon, Jun 20, 2016 at 7:46 AM, Thomas Gleixner wrote: > On Mon, 20 Jun 2016, Arjan van de Ven wrote: >> On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: >> > >> > 2) Cut off at

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Arjan van de Ven
so is there really an issue? sounds like KISS principle can apply On Mon, Jun 20, 2016 at 7:46 AM, Thomas Gleixner wrote: > On Mon, 20 Jun 2016, Arjan van de Ven wrote: >> On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: >> > >> > 2) Cut off at 37hrs for HZ=1000. We could make this

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Paul E. McKenney
On Mon, Jun 20, 2016 at 05:13:41PM +0200, Thomas Gleixner wrote: > On Mon, 20 Jun 2016, Paul E. McKenney wrote: > > > On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > > > This is the second version of the timer wheel rework series. The first > > > series > > > can be found

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Paul E. McKenney
On Mon, Jun 20, 2016 at 05:13:41PM +0200, Thomas Gleixner wrote: > On Mon, 20 Jun 2016, Paul E. McKenney wrote: > > > On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > > > This is the second version of the timer wheel rework series. The first > > > series > > > can be found

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Paul E. McKenney
On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > This is the second version of the timer wheel rework series. The first series > can be found here: > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de > > The series is also available in git: > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Paul E. McKenney
On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > This is the second version of the timer wheel rework series. The first series > can be found here: > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de > > The series is also available in git: > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Mon, 20 Jun 2016, Paul E. McKenney wrote: > On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > > This is the second version of the timer wheel rework series. The first > > series > > can be found here: > > > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Mon, 20 Jun 2016, Paul E. McKenney wrote: > On Fri, Jun 17, 2016 at 01:26:28PM -, Thomas Gleixner wrote: > > This is the second version of the timer wheel rework series. The first > > series > > can be found here: > > > >http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Mon, 20 Jun 2016, Arjan van de Ven wrote: > On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ > >option so datacenter folks can use this and people who don't care and > > want >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Mon, 20 Jun 2016, Arjan van de Ven wrote: > On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ > >option so datacenter folks can use this and people who don't care and > > want > >better batching

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Arjan van de Ven
On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ >option so datacenter folks can use this and people who don't care and want >better batching for power can use the 4ms thingy. if

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Arjan van de Ven
On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ >option so datacenter folks can use this and people who don't care and want >better batching for power can use the 4ms thingy. if there really is one

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Fri, 17 Jun 2016, Eric Dumazet wrote: > To avoid increasing probability of such events we would need to have > at least 4 ms difference between the RTO timer and delack timer. > > Meaning we have to increase both of them and increase P99 latencies of > RPC workloads. > > Maybe a switch to

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-20 Thread Thomas Gleixner
On Fri, 17 Jun 2016, Eric Dumazet wrote: > To avoid increasing probability of such events we would need to have > at least 4 ms difference between the RTO timer and delack timer. > > Meaning we have to increase both of them and increase P99 latencies of > RPC workloads. > > Maybe a switch to

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Arjan van de Ven
>To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Arjan van de Ven
>To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Eric Dumazet
On Fri, Jun 17, 2016 at 6:57 AM, Thomas Gleixner wrote: > On Fri, 17 Jun 2016, Eric Dumazet wrote: >> > >> >To achieve this capacity with HZ=1000 without increasing the storage >> > size >> >by another level, we reduced the granularity of the first wheel level >> >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Eric Dumazet
On Fri, Jun 17, 2016 at 6:57 AM, Thomas Gleixner wrote: > On Fri, 17 Jun 2016, Eric Dumazet wrote: >> > >> >To achieve this capacity with HZ=1000 without increasing the storage >> > size >> >by another level, we reduced the granularity of the first wheel level >> > from >> >1ms to

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Thomas Gleixner
On Fri, 17 Jun 2016, Eric Dumazet wrote: > > > >To achieve this capacity with HZ=1000 without increasing the storage size > >by another level, we reduced the granularity of the first wheel level > > from > >1ms to 4ms. According to our data, there is no user which relies on that > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Thomas Gleixner
On Fri, 17 Jun 2016, Eric Dumazet wrote: > > > >To achieve this capacity with HZ=1000 without increasing the storage size > >by another level, we reduced the granularity of the first wheel level > > from > >1ms to 4ms. According to our data, there is no user which relies on that > >

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Eric Dumazet
> >To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

Re: [patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Eric Dumazet
> >To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

[patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Thomas Gleixner
This is the second version of the timer wheel rework series. The first series can be found here: http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de The series is also available in git: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers Changes vs. V1: -

[patch V2 00/20] timer: Refactor the timer wheel

2016-06-17 Thread Thomas Gleixner
This is the second version of the timer wheel rework series. The first series can be found here: http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de The series is also available in git: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers Changes vs. V1: -