linux-kernel - Re: [PATCH RFC nohz_full v2 2/7] nohz_full: Add rcu_dyntick data for scalable detection of all-idle state

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]

Date:	Mon, 1 Jul 2013 08:52:20 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu
Subject: Re: [PATCH RFC nohz_full v2 2/7] nohz_full: Add rcu_dyntick data for
 scalable detection of all-idle state

On Mon, Jul 01, 2013 at 08:31:50AM -0700, Josh Triplett wrote:
> On Fri, Jun 28, 2013 at 01:10:17PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > 
> > This commit adds fields to the rcu_dyntick structure that are used to
> > detect idle CPUs.  These new fields differ from the existing ones in
> > that the existing ones consider a CPU executing in user mode to be idle,
> > where the new ones consider CPUs executing in user mode to be busy.
> 
> Can you explain, both in the commit messages and in the comments added
> by the next commit, *why* this code doesn't consider userspace a
> quiescent state?

Good point!  Does the following explain it?

	Although one of RCU's quiescent states is usermode execution,
	it is not a full-system idle state.  This is because the purpose
	of the full-system idle state is not RCU, but rather determining
	when accurate timekeeping can safely be disabled.  Whenever
	accurate timekeeping is required in a CONFIG_NO_HZ_FULL kernel,
	at least one CPU must keep the scheduling-clock tick going.
	If even one CPU is executing in user mode, accurate timekeeping
	is requires, particularly for architectures where gettimeofday()
	and friends do not enter the kernel.  Only when all CPUs are
	really and truly idle can accurate timekeeping be disabled,
	allowing all CPUs to turn off the scheduling clock interrupt,
	thus greatly improving energy efficiency.

	This naturally raises the question "Why is this code in RCU rather
	than in timekeeping?", and the answer is that RCU has the data
	and infrastructure to efficiently make this determination.

							Thanx, Paul

--
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/