On Sun, 2013-12-22 at 06:10 +0100, Mike Galbraith wrote:
> DL980 with same rt7 patchset/config, but with nohz_full=55-63 can take a
> while to make up its mind, but does kick in (this boot anyway).
While rebuilding with distro config (lard=max, but nohz_full=off)...
[ 2230.960596] [
On Sun, 2013-12-22 at 05:17 +0100, Mike Galbraith wrote:
> On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
> > On 21/12/2013 11:11, Mike Galbraith wrote:
> > >
> > > Works, modulo noisy workqueues.
> > >
> > > rtbox:~ # sleep 35 && killall pert& cgexec -g cpuset:rtcpus taskset -c 3
> > >
On Sun, 2013-12-22 at 05:17 +0100, Mike Galbraith wrote:
> On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
> > On 21/12/2013 11:11, Mike Galbraith wrote:
> > >
> > > Works, modulo noisy workqueues.
> > >
> > > rtbox:~ # sleep 35 && killall pert& cgexec -g cpuset:rtcpus taskset -c 3
> > >
On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
> On 21/12/2013 11:11, Mike Galbraith wrote:
> >
> > Works, modulo noisy workqueues.
> >
> > rtbox:~ # sleep 35 && killall pert& cgexec -g cpuset:rtcpus taskset -c 3
> > pert 5
> > [1] 5660
> > 2400.05 MHZ CPU
> > perturbation threshold 0.018
On 21/12/2013 11:11, Mike Galbraith wrote:
Works, modulo noisy workqueues.
rtbox:~ # sleep 35 && killall pert& cgexec -g cpuset:rtcpus taskset -c 3 pert 5
[1] 5660
2400.05 MHZ CPU
perturbation threshold 0.018 usecs.
pert/s: 33 >15.75us:2 min: 0.04 max: 24.14 avg: 2.51 sum/s:
On Fri, 2013-12-20 at 16:41 +0100, Sebastian Andrzej Siewior wrote:
> On 07.11.13, Thomas Gleixner wrote:
> > below should address that issue. If that works on mainline we can
> > adapt it for RT (needs a trylock(>lock) there).
>
> okay, so this is waht I'm going to take for -RT:
Works, modulo
On Fri, 2013-12-20 at 16:41 +0100, Sebastian Andrzej Siewior wrote:
On 07.11.13, Thomas Gleixner wrote:
below should address that issue. If that works on mainline we can
adapt it for RT (needs a trylock(base-lock) there).
okay, so this is waht I'm going to take for -RT:
Works, modulo
On 21/12/2013 11:11, Mike Galbraith wrote:
Works, modulo noisy workqueues.
rtbox:~ # sleep 35 killall pert cgexec -g cpuset:rtcpus taskset -c 3 pert 5
[1] 5660
2400.05 MHZ CPU
perturbation threshold 0.018 usecs.
pert/s: 33 15.75us:2 min: 0.04 max: 24.14 avg: 2.51 sum/s:
On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
On 21/12/2013 11:11, Mike Galbraith wrote:
Works, modulo noisy workqueues.
rtbox:~ # sleep 35 killall pert cgexec -g cpuset:rtcpus taskset -c 3
pert 5
[1] 5660
2400.05 MHZ CPU
perturbation threshold 0.018 usecs.
pert/s:
On Sun, 2013-12-22 at 05:17 +0100, Mike Galbraith wrote:
On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
On 21/12/2013 11:11, Mike Galbraith wrote:
Works, modulo noisy workqueues.
rtbox:~ # sleep 35 killall pert cgexec -g cpuset:rtcpus taskset -c 3
pert 5
[1] 5660
On Sun, 2013-12-22 at 05:17 +0100, Mike Galbraith wrote:
On Sat, 2013-12-21 at 19:21 +0200, Muli Baron wrote:
On 21/12/2013 11:11, Mike Galbraith wrote:
Works, modulo noisy workqueues.
rtbox:~ # sleep 35 killall pert cgexec -g cpuset:rtcpus taskset -c 3
pert 5
[1] 5660
On Sun, 2013-12-22 at 06:10 +0100, Mike Galbraith wrote:
DL980 with same rt7 patchset/config, but with nohz_full=55-63 can take a
while to make up its mind, but does kick in (this boot anyway).
While rebuilding with distro config (lard=max, but nohz_full=off)...
[ 2230.960596] [
On 07.11.13, Thomas Gleixner wrote:
> below should address that issue. If that works on mainline we can
> adapt it for RT (needs a trylock(>lock) there).
okay, so this is waht I'm going to take for -RT:
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 79a7a35..bdbf77db 100644
On 07.11.13, Thomas Gleixner wrote:
below should address that issue. If that works on mainline we can
adapt it for RT (needs a trylock(base-lock) there).
okay, so this is waht I'm going to take for -RT:
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 79a7a35..bdbf77db
On Tue, 12 Nov 2013, Mike Galbraith wrote:
> FYI, shiny new (and virgin) 3.12.0-rt1 nohz_full config is deadlock
> prone. I was measuring fastpath cost yesterday with pinned pipe-test..
>
> x3550 M3 E5620 (bloatware config)
> CONFIG_NO_HZ_IDLE - CPU3
> 2.957012 usecs/loop -- avg 2.957012 676.4
On Thu, 2013-11-07 at 14:13 +0100, Thomas Gleixner wrote:
> On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
> > On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
> > > Though it's not a full solution. It needs some thought versus the
> > > softirq code of timers. Assume we have only
On Thu, 2013-11-07 at 14:13 +0100, Thomas Gleixner wrote:
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
Though it's not a full solution. It needs some thought versus the
softirq code of timers. Assume we have only one
On Tue, 12 Nov 2013, Mike Galbraith wrote:
FYI, shiny new (and virgin) 3.12.0-rt1 nohz_full config is deadlock
prone. I was measuring fastpath cost yesterday with pinned pipe-test..
x3550 M3 E5620 (bloatware config)
CONFIG_NO_HZ_IDLE - CPU3
2.957012 usecs/loop -- avg 2.957012 676.4 KHz
On Fri, Nov 08, 2013 at 03:53:47PM +0100, Mike Galbraith wrote:
> On Fri, 2013-11-08 at 15:29 +0100, Frederic Weisbecker wrote:
> > On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > > On Fri, 2013-11-08 at
On Fri, Nov 08, 2013 at 06:45:34AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 08, 2013 at 03:29:38PM +0100, Frederic Weisbecker wrote:
> > On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > > On Fri,
On Fri, 2013-11-08 at 15:29 +0100, Frederic Weisbecker wrote:
> On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> > > > On Fri, Nov 08, 2013 at
On Fri, Nov 08, 2013 at 03:29:38PM +0100, Frederic Weisbecker wrote:
> On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> > > > On Fri, Nov 08,
On Fri, 2013-11-08 at 06:03 -0800, Paul E. McKenney wrote:
> On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
> > > > On Thu, 2013-11-07 at 19:23
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
> > > > On Thu, 2013-11-07 at
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> > On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
> > > On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
> > >
> > > > An untested patch that
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
> On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
> > On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
> >
> > > An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
> >
> > Yup, toasted.
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
> On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
>
> > An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
>
> Yup, toasted.
You lost me on this one. If my patch broke your system, any chance of
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
Yup, toasted.
You lost me on this one. If my patch broke your system, any chance of
any
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
Yup, toasted.
You lost
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
An untested patch that gets rid of
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 19:23 -0800,
On Fri, 2013-11-08 at 06:03 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 08:31:20AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 19:23 -0800, Paul
On Fri, Nov 08, 2013 at 03:29:38PM +0100, Frederic Weisbecker wrote:
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at
On Fri, 2013-11-08 at 15:29 +0100, Frederic Weisbecker wrote:
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37 -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 08:31:20AM
On Fri, Nov 08, 2013 at 06:45:34AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 03:29:38PM +0100, Frederic Weisbecker wrote:
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at
On Fri, Nov 08, 2013 at 03:53:47PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 15:29 +0100, Frederic Weisbecker wrote:
On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
On Fri, 2013-11-08 at 04:37
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
> An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
Yup, toasted.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Thu, Nov 07, 2013 at 05:31:08AM +0100, Mike Galbraith wrote:
> On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
>
> > > I bet you are trying to work around some of the side effects of the
> > > occasional tick which is
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
> > Though it's not a full solution. It needs some thought versus the
> > softirq code of timers. Assume we have only one timer queued 1000
> > ticks into the future. So this change
On Thu, 2013-11-07 at 12:21 +0100, Thomas Gleixner wrote:
> Mike,
>
> On Thu, 7 Nov 2013, Mike Galbraith wrote:
>
> > On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> > > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
> >
> > > > I bet you are trying to work around some
On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
> Mike,
>
> On Thu, 7 Nov 2013, Mike Galbraith wrote:
>
> > On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> > > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
> >
> > > > I bet you are trying to work around
Mike,
On Thu, 7 Nov 2013, Mike Galbraith wrote:
> On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
>
> > > I bet you are trying to work around some of the side effects of the
> > > occasional tick which is still necessary
Mike,
On Thu, 7 Nov 2013, Mike Galbraith wrote:
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
I bet you are trying to work around some of the side effects of the
occasional tick which is still necessary despite of
On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
Mike,
On Thu, 7 Nov 2013, Mike Galbraith wrote:
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
I bet you are trying to work around some of the
On Thu, 2013-11-07 at 12:21 +0100, Thomas Gleixner wrote:
Mike,
On Thu, 7 Nov 2013, Mike Galbraith wrote:
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
I bet you are trying to work around some of the side
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:
Though it's not a full solution. It needs some thought versus the
softirq code of timers. Assume we have only one timer queued 1000
ticks into the future. So this change will
On Thu, Nov 07, 2013 at 05:31:08AM +0100, Mike Galbraith wrote:
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
I bet you are trying to work around some of the side effects of the
occasional tick which is still
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
Yup, toasted.
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
> > I bet you are trying to work around some of the side effects of the
> > occasional tick which is still necessary despite of full nohz, right?
>
> Nope, I wanted to check out
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
> On Thu, 31 Oct 2013, Mike Galbraith wrote:
>
> > Hi Frederic,
> >
> > The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
> > when an otherwise lonely task takes the timer interrupt. Deferring to
> > softirq
On Thu, 31 Oct 2013, Mike Galbraith wrote:
> Hi Frederic,
>
> The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
> when an otherwise lonely task takes the timer interrupt. Deferring to
> softirq processing time. works.
-ENOPARSE
What the heck is this patch doing aside
On Thu, 31 Oct 2013, Mike Galbraith wrote:
Hi Frederic,
The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
when an otherwise lonely task takes the timer interrupt. Deferring to
softirq processing time. works.
-ENOPARSE
What the heck is this patch doing aside of
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
On Thu, 31 Oct 2013, Mike Galbraith wrote:
Hi Frederic,
The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
when an otherwise lonely task takes the timer interrupt. Deferring to
softirq processing time.
On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
I bet you are trying to work around some of the side effects of the
occasional tick which is still necessary despite of full nohz, right?
Nope, I wanted to check out cost
Hi Frederic,
The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
when an otherwise lonely task takes the timer interrupt. Deferring to
softirq processing time. works.
---
kernel/sched/core.c |2 +-
kernel/softirq.c | 10 ++
Hi Frederic,
The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
when an otherwise lonely task takes the timer interrupt. Deferring to
softirq processing time. works.
---
kernel/sched/core.c |2 +-
kernel/softirq.c | 10 ++
56 matches
Mail list logo
