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
> ca
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 se
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, &ts
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 looking
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 han
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 n
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 is
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 meril
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 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 11:12:
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 enab
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 http:
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. Bu
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 rcu_prepare
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 happen
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 co
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 en
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. B
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 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% idle,
27 matches
Mail list logo
