linux-kernel - Re: [PATCH RFC tip/core/rcu] Add callback-free CPUs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1346950736.18408.43.camel@twins>
Date:	Thu, 06 Sep 2012 18:58:56 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...icios.com, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu, patches@...aro.org
Subject: Re: [PATCH RFC tip/core/rcu] Add callback-free CPUs

On Thu, 2012-09-06 at 09:47 -0700, Paul E. McKenney wrote:
> The key point is "would simple put RCU into extended quiescent state".
> This can only happen if the CPU has no callbacks.  If the CPU does have
> callbacks, then RCU will need to do some work to advance the callbacks.
> Advancing the callbacks requires that RCU periodically do work on that
> CPU, resulting in OS jitter.

But since its then not actually in adaptive-tick mode (the tick is still
running) who cares? It will only disable the tick once all preconditions
are met, this includes RCU being in extended qs, so until that time...

> > That way you could run the entire state thing from a kthread with random
> > affinity, all 'per-cpu' data would still be fine since only the one
> > kthread will access it, even though locality might suffer somewhat.
> 
> Well, the current patch set does move much of the grace-period machinery
> to a kthread.  Much of the remaining work needs to remain on the CPUs
> (at least those not in an extended quiescent state) in order to keep
> the overhead of the read-side primitives and scheduler hooks inexpensive. 

Ah indeed, what you're saying is that the data required by those hooks
needs to be accessed locally in order to avoid proper atomic ops.

So then you do indeed need to break the state machine into two parts,
and I guess that's the bit you're struggling with.

Still I would not make this more complex than it needs to be, if the
tick is running we can use this to drive the state machine, if its not,
we are in extended qs and we don't need to drive the tick.


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