Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f2094107 authored by Paul E. McKenney's avatar Paul E. McKenney
Browse files

Merge branches 'doc.2017.04.12a', 'fixes.2017.04.19a' and 'srcu.2017.04.21a' into HEAD 

doc.2017.04.12a: Documentation updates
fixes.2017.04.19a: Miscellaneous fixes
srcu.2017.04.21a: Parallelize SRCU callback handling
parents b26cfc48 bfd090be bcbfdd01

Documentation/RCU/00-INDEX

+1 −1
Original line number Diff line number Diff line
@@ -17,7 +17,7 @@ rcu_dereference.txt 
rcubarrier.txt

	- RCU and Unloadable Modules

rculist_nulls.txt

	- RCU list primitives for use with SLAB_DESTROY_BY_RCU

	- RCU list primitives for use with SLAB_TYPESAFE_BY_RCU

rcuref.txt

	- Reference-count design for elements of lists/arrays protected by RCU

rcu.txt

Documentation/RCU/Design/Data-Structures/Data-Structures.html

+25 −1
Original line number Diff line number Diff line
@@ -1185,6 +1185,9 @@ Its fields are as follows: 
  1   int dynticks_nesting;

  2   int dynticks_nmi_nesting;

  3   atomic_t dynticks;

  4   bool rcu_need_heavy_qs;

  5   unsigned long rcu_qs_ctr;

  6   bool rcu_urgent_qs;

</pre>



<p>The <tt>-&gt;dynticks_nesting</tt> field counts the
@@ -1198,11 +1201,32 @@ NMIs are counted by the <tt>-&gt;dynticks_nmi_nesting</tt> 
field, except that NMIs that interrupt non-dyntick-idle execution

are not counted.



</p><p>Finally, the <tt>-&gt;dynticks</tt> field counts the corresponding

</p><p>The <tt>-&gt;dynticks</tt> field counts the corresponding

CPU's transitions to and from dyntick-idle mode, so that this counter

has an even value when the CPU is in dyntick-idle mode and an odd

value otherwise.



</p><p>The <tt>-&gt;rcu_need_heavy_qs</tt> field is used

to record the fact that the RCU core code would really like to

see a quiescent state from the corresponding CPU, so much so that

it is willing to call for heavy-weight dyntick-counter operations.

This flag is checked by RCU's context-switch and <tt>cond_resched()</tt>

code, which provide a momentary idle sojourn in response.



</p><p>The <tt>-&gt;rcu_qs_ctr</tt> field is used to record

quiescent states from <tt>cond_resched()</tt>.

Because <tt>cond_resched()</tt> can execute quite frequently, this

must be quite lightweight, as in a non-atomic increment of this

per-CPU field.



</p><p>Finally, the <tt>-&gt;rcu_urgent_qs</tt> field is used to record

the fact that the RCU core code would really like to see a quiescent

state from the corresponding CPU, with the various other fields indicating

just how badly RCU wants this quiescent state.

This flag is checked by RCU's context-switch and <tt>cond_resched()</tt>

code, which, if nothing else, non-atomically increment <tt>-&gt;rcu_qs_ctr</tt>

in response.



<table>

<tr><th>&nbsp;</th></tr>

<tr><th align="left">Quick Quiz:</th></tr>

Documentation/RCU/rculist_nulls.txt

+3 −3
Original line number Diff line number Diff line 
Using hlist_nulls to protect read-mostly linked lists and

objects using SLAB_DESTROY_BY_RCU allocations.

objects using SLAB_TYPESAFE_BY_RCU allocations.



Please read the basics in Documentation/RCU/listRCU.txt
@@ -7,7 +7,7 @@ Using special makers (called 'nulls') is a convenient way 
to solve following problem :



A typical RCU linked list managing objects which are

allocated with SLAB_DESTROY_BY_RCU kmem_cache can

allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can

use following algos :



1) Lookup algo
@@ -96,7 +96,7 @@ unlock_chain(); // typically a spin_unlock() 
3) Remove algo

--------------

Nothing special here, we can use a standard RCU hlist deletion.

But thanks to SLAB_DESTROY_BY_RCU, beware a deleted object can be reused

But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused

very very fast (before the end of RCU grace period)



if (put_last_reference_on(obj) {

Documentation/RCU/whatisRCU.txt

+2 −1
Original line number Diff line number Diff line
@@ -928,7 +928,8 @@ d. Do you need RCU grace periods to complete even in the face 


e.	Is your workload too update-intensive for normal use of

	RCU, but inappropriate for other synchronization mechanisms?

	If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!

	If so, consider SLAB_TYPESAFE_BY_RCU (which was originally

	named SLAB_DESTROY_BY_RCU).  But please be careful!



f.	Do you need read-side critical sections that are respected

	even though they are in the middle of the idle loop, during

arch/Kconfig

+3 −0
Original line number Diff line number Diff line
@@ -320,6 +320,9 @@ config HAVE_CMPXCHG_LOCAL 
config HAVE_CMPXCHG_DOUBLE

	bool



config ARCH_WEAK_RELEASE_ACQUIRE

	bool



config ARCH_WANT_IPC_PARSE_VERSION

	bool