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
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
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
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.
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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:~ #
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:~ #
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
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
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:~ #
> >
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:~ #
> >
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
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
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:~ #
>
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:~ #
>
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:
>
>
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:
>
>
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
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
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
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
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
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
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
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
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:
>
>
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:
>
>
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
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
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
>
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
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
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
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
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
>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
>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
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
>> >
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
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
> >
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
> >
>
>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
>
>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
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:
-
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:
-
58 matches
Mail list logo