linux-kernel - Re: [PATCH 2/4] timer: relax tick stop in idle entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151116223117.GK5184@linux.vnet.ibm.com>
Date:	Mon, 16 Nov 2015 14:31:17 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Len Brown <len.brown@...el.com>,
	Rafael Wysocki <rafael.j.wysocki@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	Paul Turner <pjt@...gle.com>,
	Josh Triplett <josh@...htriplett.org>
Subject: Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Mon, Nov 16, 2015 at 01:51:26PM -0800, Jacob Pan wrote:
> On Mon, 16 Nov 2015 16:06:57 +0100 (CET)
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > >           <idle>-0     [000]    30.093474: bprint:
> > > __tick_nohz_idle_enter: JPAN: tick_nohz_stop_sched_tick 609 delta
> > > 1000000 [JP] but sees delta is exactly 1 tick away. didn't stop
> > > tick.  
> > 
> > If the delta is 1 tick then it is not supposed to stop it. Did you
> > ever try to figure out WHY it is 1 tick?
> > 
> > There are two code pathes which can set it to basemono + TICK_NSEC:
> > 
> >         if (rcu_needs_cpu(basemono, &next_rcu) ||
> >             arch_needs_cpu() || irq_work_needs_cpu()) {
> >                 next_tick = basemono + TICK_NSEC;
> >         } else {
> >                 next_tmr = get_next_timer_interrupt(basejiff,
> > basemono); ts->next_timer = next_tmr;
> >                 /* Take the next rcu event into account */
> >                 next_tick = next_rcu < next_tmr ? next_rcu : next_tmr;
> >         }
> > 
> > Can you please figure out WHY the tick is requested to continue
> > instead of blindly wreckaging the logic in that code?
> 
> Looks like the it hits in both cases during forced idle.
> + Josh
> + Paul
> 
> For the first case, it is always related to RCU. I found there are two
> CONFIG options to avoid this undesired tick in idle loop.
> 1. enable CONFIG_RCU_NOCB_CPU_ALL, offload to orcu kthreads
> 2. or enable CONFIG_RCU_FAST_NO_HZ (enter dytick idle w/ rcu callback)
> 
> Either one works but my concern is that users may not realize the
> intricate CONFIG_ options and how they translate into energy savings.
> Consulted with Josh, it seems we could add a check here to recognize
> the forced idle state and relax rcu_needs_cpu() to return false even it
> has callbacks. Since we are blocking everybody for a short time (5 ticks
> default). It should not impact synchronize and kfree rcu.

Or we could just set things up so that whatever Kconfig you are using
to enable this state causes CONFIG_RCU_NOCB_CPU_ALL to also be enabled.
Or that causes CONFIG_RCU_FAST_NO_HZ to also be enabled, if that works
better for you.

Just out of curiosity, what is the purpose of the forced idle state?
Thermal control or some such?

							Thanx, Paul

> For the second case, which is much more rare, I think we do have next
> timer exactly one tick away. Just don't know why tick will continue into
> idle loop.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/