linux-kernel - Re: [PATCH tip/core/rcu 0/5] Fix for cond

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:	Fri, 20 Jun 2014 15:11:20 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	josh@...htriplett.org
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	niv@...ibm.com, tglx@...utronix.de, peterz@...radead.org,
	rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
	dvhart@...ux.intel.com, fweisbec@...il.com, oleg@...hat.com,
	sbw@....edu
Subject: Re: [PATCH tip/core/rcu 0/5] Fix for cond_resched performance
 regression

On Fri, Jun 20, 2014 at 02:24:23PM -0700, josh@...htriplett.org wrote:
> On Fri, Jun 20, 2014 at 12:12:36PM -0700, Paul E. McKenney wrote:
> > o	Make cond_resched() a no-op for PREEMPT=y.  This might well turn
> > 	out to be a good thing, but it doesn't help give RCU the quiescent
> > 	states that it needs.
> 
> What about doing this, together with letting the fqs logic poke
> un-quiesced kernel code as needed?  That way, rather than having
> cond_resched do any work, you have the fqs logic recognize that a
> particular CPU has gone too long without quiescing, without disturbing
> that CPU at all if it hasn't gone too long.

My next stop is to post the previous series, but with a couple of
exports and one bug fix uncovered by testing thus far, but after
another round of testing.  Then I am going to take a close look at
this one:

o	Push the checks further into cond_resched(), so that the
	fastpath does the same sequence of instructions that the original
	did.  This might work well, but requires IPIs, which are not so
	good for latencies on the remote CPU.  It nevertheless might be a
	decent long-term solution given that if your CPU is spending many
	jiffies looping in the kernel, you aren't getting good latencies
	anyway.  It also has the benefit of allowing RCU to take advantage
	of the implicit quiescent states of all cond_resched() calls,
	and of eliminating the need for a separate cond_resched_rcu_qs()
	and for RCU_COND_RESCHED_QS.

The one you call out is of course interesting as well.  But there are
a couple of questions:

1.	Why wasn't cond_resched() a no-op in CONFIG_PREEMPT to start
	with?  It just seems to obvious a thing to do for it to possibly
	be an oversight.  (What, me paranoid?)

2.	When RCU recognizes that a particular CPU has gone too long,
	exactly what are you suggesting that RCU do about it?  When
	formulating your answer, please give due consideration to the
	implications of that CPU being a NO_HZ_FULL CPU.  ;-)

Probably other questions as well, but those are the ones that come to
mind immediately.

							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/