On Wed, 9 Apr 2014 21:26:51 +0530
Viresh Kumar wrote:
> When HRES isn't enabled and NOHZ isn't enabled as well, in that
> case we should stick to the periodic code from tick-common.c and
> the oneshot options of tick_nohz_switch_to_nohz() or
> hrtimer_switch_to_hres() shouldn't be used. And so,
On 9 April 2014 21:09, Steven Rostedt wrote:
> Reading even more of the code, now I'm totally confused :-)
:)
> When tick_setup_sched_timer() is called, if tick_nohz_enabled is set,
> then we set tick_nohz_active.
correct.
> This gets called by hrtimer_switch_to_hres(), and before that is
>
On Wed, 9 Apr 2014 11:31:43 -0400
Steven Rostedt wrote:
>
> Hmm, looking at the code, I see it probably should still do the check.
>
> OK, nevermind ;-)
Reading even more of the code, now I'm totally confused :-)
When tick_setup_sched_timer() is called, if tick_nohz_enabled is set,
then we
On 9 April 2014 21:01, Steven Rostedt wrote:
>> Do we? This is only called by tick_check_oneshot_change() which has the
>> following:
>>
>> int tick_check_oneshot_change(int allow_nohz)
>> {
>> struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
>>
>> if (!test_and_clear_bit(0,
On Wed, 9 Apr 2014 11:29:50 -0400
Steven Rostedt wrote:
> On Wed, 9 Apr 2014 20:50:59 +0530
> Viresh Kumar wrote:
>
> > On 9 April 2014 20:01, Steven Rostedt wrote:
> > > Ouch! You are correct, this part of the patch makes no sense. That's
> > > what I get for reviewing a patch and not
On Wed, 9 Apr 2014 20:50:59 +0530
Viresh Kumar wrote:
> On 9 April 2014 20:01, Steven Rostedt wrote:
> > Ouch! You are correct, this part of the patch makes no sense. That's
> > what I get for reviewing a patch and not looking at all the code around
> > the changes. (another kernel developer
On 9 April 2014 20:01, Steven Rostedt wrote:
> Ouch! You are correct, this part of the patch makes no sense. That's
> what I get for reviewing a patch and not looking at all the code around
> the changes. (another kernel developer hangs head in shame :-( )
>
> I think that if statement should be
On Wed, Apr 09, 2014 at 07:21:53PM +0530, Viresh Kumar wrote:
> On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner wrote:
> > Subject: NOHZ: Check for nohz active instead of nohz enabled
> >
> > RCU and the fine grained idle time accounting functions check
> > tick_nohz_enabled. But that variable
On Wed, 9 Apr 2014 19:21:53 +0530
Viresh Kumar wrote:
> On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner wrote:
> > Subject: NOHZ: Check for nohz active instead of nohz enabled
> >
> > RCU and the fine grained idle time accounting functions check
> > tick_nohz_enabled. But that variable is
On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner wrote:
> Subject: NOHZ: Check for nohz active instead of nohz enabled
>
> RCU and the fine grained idle time accounting functions check
> tick_nohz_enabled. But that variable is merily telling that NOHZ has
> been enabled in the config and not been
On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner t...@linutronix.de wrote:
Subject: NOHZ: Check for nohz active instead of nohz enabled
RCU and the fine grained idle time accounting functions check
tick_nohz_enabled. But that variable is merily telling that NOHZ has
been enabled in the config
On Wed, 9 Apr 2014 19:21:53 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner t...@linutronix.de wrote:
Subject: NOHZ: Check for nohz active instead of nohz enabled
RCU and the fine grained idle time accounting functions check
On Wed, Apr 09, 2014 at 07:21:53PM +0530, Viresh Kumar wrote:
On Thu, Nov 14, 2013 at 1:31 AM, Thomas Gleixner t...@linutronix.de wrote:
Subject: NOHZ: Check for nohz active instead of nohz enabled
RCU and the fine grained idle time accounting functions check
tick_nohz_enabled. But that
On 9 April 2014 20:01, Steven Rostedt rost...@goodmis.org wrote:
Ouch! You are correct, this part of the patch makes no sense. That's
what I get for reviewing a patch and not looking at all the code around
the changes. (another kernel developer hangs head in shame :-( )
I think that if
On Wed, 9 Apr 2014 20:50:59 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
On 9 April 2014 20:01, Steven Rostedt rost...@goodmis.org wrote:
Ouch! You are correct, this part of the patch makes no sense. That's
what I get for reviewing a patch and not looking at all the code around
the
On Wed, 9 Apr 2014 11:29:50 -0400
Steven Rostedt rost...@goodmis.org wrote:
On Wed, 9 Apr 2014 20:50:59 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
On 9 April 2014 20:01, Steven Rostedt rost...@goodmis.org wrote:
Ouch! You are correct, this part of the patch makes no sense. That's
On 9 April 2014 21:01, Steven Rostedt rost...@goodmis.org wrote:
Do we? This is only called by tick_check_oneshot_change() which has the
following:
int tick_check_oneshot_change(int allow_nohz)
{
struct tick_sched *ts = __get_cpu_var(tick_cpu_sched);
if (!test_and_clear_bit(0,
On Wed, 9 Apr 2014 11:31:43 -0400
Steven Rostedt rost...@goodmis.org wrote:
Hmm, looking at the code, I see it probably should still do the check.
OK, nevermind ;-)
Reading even more of the code, now I'm totally confused :-)
When tick_setup_sched_timer() is called, if tick_nohz_enabled is
On 9 April 2014 21:09, Steven Rostedt rost...@goodmis.org wrote:
Reading even more of the code, now I'm totally confused :-)
:)
When tick_setup_sched_timer() is called, if tick_nohz_enabled is set,
then we set tick_nohz_active.
correct.
This gets called by hrtimer_switch_to_hres(), and
On Wed, 9 Apr 2014 21:26:51 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
When HRES isn't enabled and NOHZ isn't enabled as well, in that
case we should stick to the periodic code from tick-common.c and
the oneshot options of tick_nohz_switch_to_nohz() or
hrtimer_switch_to_hres()
On Wed, Nov 13, 2013 at 09:01:57PM +0100, Thomas Gleixner wrote:
> On Wed, 13 Nov 2013, Paul E. McKenney wrote:
> > On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
> > > On Wed, 13 Nov 2013 08:18:29 -0800
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Wed, Nov 13, 2013 at
On Wed, Nov 13, 2013 at 09:01:57PM +0100, Thomas Gleixner wrote:
On Wed, 13 Nov 2013, Paul E. McKenney wrote:
On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 08:18:29 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Nov 13, 2013
On Wed, Nov 13, 2013 at 03:07:45PM -0500, Steven Rostedt wrote:
> On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
> Thomas Gleixner wrote:
>
>
> > >
> > Subject: NOHZ: Check for nohz active instead of nohz enabled
> >
> > RCU and the fine grained idle time accounting functions check
>
On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
Thomas Gleixner wrote:
> >
> Subject: NOHZ: Check for nohz active instead of nohz enabled
>
> RCU and the fine grained idle time accounting functions check
> tick_nohz_enabled. But that variable is merily telling that NOHZ has
> been
On Wed, 13 Nov 2013, Paul E. McKenney wrote:
> On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
> > On Wed, 13 Nov 2013 08:18:29 -0800
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
> > > > On Wed, 13 Nov 2013 17:07:18 +0100
On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
> On Wed, 13 Nov 2013 08:18:29 -0800
> "Paul E. McKenney" wrote:
>
> > On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
> > > On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
> > > Thomas Gleixner wrote:
> > >
> > >
> > >
On Wed, 13 Nov 2013 17:21:53 +0100 (CET)
Thomas Gleixner wrote:
> Frozen shark time
As long as it's not aimed at me ;-)
-- Steve
--
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
On Wed, 13 Nov 2013 08:18:29 -0800
"Paul E. McKenney" wrote:
> On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
> > On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
> > Thomas Gleixner wrote:
> >
> >
> > > Right. It's telling you if NOHZ is enabled. It's not telling you that
> > > NOHZ
On Wed, 13 Nov 2013, Thomas Gleixner wrote:
> On Wed, 13 Nov 2013, Steven Rostedt wrote:
>
> > On Wed, 13 Nov 2013 10:31:34 -0500
> > Steven Rostedt wrote:
> >
> > > The trace does indeed show that a tick is happening, as the config has
> > > HZ=250 (4ms) and we see a tick happen every 4ms.
On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
> On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
> Thomas Gleixner wrote:
>
>
> > Right. It's telling you if NOHZ is enabled. It's not telling you that
> > NOHZ is active.
>
> Yeah, which makes this code rather silly:
>
> in
On Wed, Nov 13, 2013 at 04:50:20PM +0100, Thomas Gleixner wrote:
> On Wed, 13 Nov 2013, Steven Rostedt wrote:
> > > I'm not saying that we are actually getting into nohz, but something
> > > with the nohz code is messing with cpu accounting.
> >
> > The trace does indeed show that a tick is
On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
Thomas Gleixner wrote:
> Right. It's telling you if NOHZ is enabled. It's not telling you that
> NOHZ is active.
Yeah, which makes this code rather silly:
in rcu_prepare_for_idle():
/* Handle nohz enablement switches conservatively. */
On Wed, 13 Nov 2013, Steven Rostedt wrote:
> On Wed, 13 Nov 2013 10:31:34 -0500
> Steven Rostedt wrote:
>
> > The trace does indeed show that a tick is happening, as the config has
> > HZ=250 (4ms) and we see a tick happen every 4ms. But for some reason,
> > we don't update the the idle time
On Wed, 13 Nov 2013 10:31:34 -0500
Steven Rostedt wrote:
> The trace does indeed show that a tick is happening, as the config has
> HZ=250 (4ms) and we see a tick happen every 4ms. But for some reason,
> we don't update the the idle time correctly when nohz is enabled.
>
> When I say nohz is
On Wed, 13 Nov 2013, Steven Rostedt wrote:
> > I'm not saying that we are actually getting into nohz, but something
> > with the nohz code is messing with cpu accounting.
>
> The trace does indeed show that a tick is happening, as the config has
> HZ=250 (4ms) and we see a tick happen every 4ms.
On Wed, 13 Nov 2013 10:21:53 -0500
Steven Rostedt wrote:
trace-cmd record -p function -l '*nohz*' -l account_process_tick -e sched_switch
>
> rcu_sche-9 0d... 6858.618033: sched_switch: rcu_sched:9 [120]
> S ==> swapper/0:0 [120]
> -0 0 6858.618082: function:
On Wed, 13 Nov 2013, Matthew Whitehead wrote:
> I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
> It arises when nohz=on and goes away with nohz=off. On a crusty dual
> Pentium-1
> system that is completely idle, the sar utility reports 0% idle time on cpu0
> and
I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
It arises when nohz=on and goes away with nohz=off. On a crusty dual Pentium-1
system that is completely idle, the sar utility reports 0% idle time on cpu0
and 100% idle on cpu1. Cpu0 _should_ also be reporting 100%
I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
It arises when nohz=on and goes away with nohz=off. On a crusty dual Pentium-1
system that is completely idle, the sar utility reports 0% idle time on cpu0
and 100% idle on cpu1. Cpu0 _should_ also be reporting 100%
On Wed, 13 Nov 2013, Matthew Whitehead wrote:
I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
It arises when nohz=on and goes away with nohz=off. On a crusty dual
Pentium-1
system that is completely idle, the sar utility reports 0% idle time on cpu0
and 100%
On Wed, 13 Nov 2013 10:21:53 -0500
Steven Rostedt rost...@goodmis.org wrote:
trace-cmd record -p function -l '*nohz*' -l account_process_tick -e sched_switch
rcu_sche-9 0d... 6858.618033: sched_switch: rcu_sched:9 [120]
S == swapper/0:0 [120]
idle-0 0 6858.618082:
On Wed, 13 Nov 2013, Steven Rostedt wrote:
I'm not saying that we are actually getting into nohz, but something
with the nohz code is messing with cpu accounting.
The trace does indeed show that a tick is happening, as the config has
HZ=250 (4ms) and we see a tick happen every 4ms. But for
On Wed, 13 Nov 2013 10:31:34 -0500
Steven Rostedt rost...@goodmis.org wrote:
The trace does indeed show that a tick is happening, as the config has
HZ=250 (4ms) and we see a tick happen every 4ms. But for some reason,
we don't update the the idle time correctly when nohz is enabled.
When I
On Wed, 13 Nov 2013, Steven Rostedt wrote:
On Wed, 13 Nov 2013 10:31:34 -0500
Steven Rostedt rost...@goodmis.org wrote:
The trace does indeed show that a tick is happening, as the config has
HZ=250 (4ms) and we see a tick happen every 4ms. But for some reason,
we don't update the the
On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Right. It's telling you if NOHZ is enabled. It's not telling you that
NOHZ is active.
Yeah, which makes this code rather silly:
in rcu_prepare_for_idle():
/* Handle nohz enablement switches
On Wed, Nov 13, 2013 at 04:50:20PM +0100, Thomas Gleixner wrote:
On Wed, 13 Nov 2013, Steven Rostedt wrote:
I'm not saying that we are actually getting into nohz, but something
with the nohz code is messing with cpu accounting.
The trace does indeed show that a tick is happening, as
On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Right. It's telling you if NOHZ is enabled. It's not telling you that
NOHZ is active.
Yeah, which makes this code rather silly:
in
On Wed, 13 Nov 2013, Thomas Gleixner wrote:
On Wed, 13 Nov 2013, Steven Rostedt wrote:
On Wed, 13 Nov 2013 10:31:34 -0500
Steven Rostedt rost...@goodmis.org wrote:
The trace does indeed show that a tick is happening, as the config has
HZ=250 (4ms) and we see a tick happen every
On Wed, 13 Nov 2013 08:18:29 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Right. It's telling you if NOHZ is enabled. It's
On Wed, 13 Nov 2013 17:21:53 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Frozen shark time
As long as it's not aimed at me ;-)
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 08:18:29 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 17:07:18 +0100 (CET)
Thomas Gleixner
On Wed, 13 Nov 2013, Paul E. McKenney wrote:
On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 08:18:29 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Nov 13, 2013 at 11:12:57AM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013
On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Subject: NOHZ: Check for nohz active instead of nohz enabled
RCU and the fine grained idle time accounting functions check
tick_nohz_enabled. But that variable is merily telling that NOHZ
On Wed, Nov 13, 2013 at 03:07:45PM -0500, Steven Rostedt wrote:
On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
Thomas Gleixner t...@linutronix.de wrote:
Subject: NOHZ: Check for nohz active instead of nohz enabled
RCU and the fine grained idle time accounting functions
54 matches
Mail list logo
