<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/include/trace/events/rcu.h, branch linux-4.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-01-23T19:44:18Z</updated>
<entry>
<title>rcu: Check cond_resched_rcu_qs() state less often to reduce GP overhead</title>
<updated>2017-01-23T19:44:18Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2016-11-30T19:21:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a19b46a5c17b12ef0691df19c676ba3da330a57'/>
<id>urn:sha1:3a19b46a5c17b12ef0691df19c676ba3da330a57</id>
<content type='text'>
Commit 4a81e8328d37 ("rcu: Reduce overhead of cond_resched() checks
for RCU") moved quiescent-state generation out of cond_resched()
and commit bde6c3aa9930 ("rcu: Provide cond_resched_rcu_qs() to force
quiescent states in long loops") introduced cond_resched_rcu_qs(), and
commit 5cd37193ce85 ("rcu: Make cond_resched_rcu_qs() apply to normal RCU
flavors") introduced the per-CPU rcu_qs_ctr variable, which is frequently
polled by the RCU core state machine.

This frequent polling can increase grace-period rate, which in turn
increases grace-period overhead, which is visible in some benchmarks
(for example, the "open1" benchmark in Anton Blanchard's "will it scale"
suite).  This commit therefore reduces the rate at which rcu_qs_ctr
is polled by moving that polling into the force-quiescent-state (FQS)
machinery, and by further polling it only after the grace period has
been in effect for at least jiffies_till_sched_qs jiffies.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
</content>
</entry>
<entry>
<title>torture: Trace long read-side delays</title>
<updated>2016-11-14T18:46:30Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2016-10-11T01:26:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d0af39e89ec59fe7c92c4bcbc2d652ea4c0ee644'/>
<id>urn:sha1:d0af39e89ec59fe7c92c4bcbc2d652ea4c0ee644</id>
<content type='text'>
Although rcutorture will occasionally do a 50-millisecond grace-period
delay, these delays are quite rare.  And rightly so, because otherwise
the read rate would be quite low.  Thie means that it can be important
to identify whether or not a given run contained a long-delay read.
This commit therefore inserts a trace_rcu_torture_read() event to flag
runs containing long delays.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Enforce expedited-GP fairness via funnel wait queue</title>
<updated>2016-03-31T20:34:08Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2016-01-31T01:57:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f6a12f34a448cc8a624070fd365c29c890138a48'/>
<id>urn:sha1:f6a12f34a448cc8a624070fd365c29c890138a48</id>
<content type='text'>
The current mutex-based funnel-locking approach used by expedited grace
periods is subject to severe unfairness.  The problem arises when a
few tasks, making a path from leaves to root, all wake up before other
tasks do.  A new task can then follow this path all the way to the root,
which needlessly delays tasks whose grace period is done, but who do
not happen to acquire the lock quickly enough.

This commit avoids this problem by maintaining per-rcu_node wait queues,
along with a per-rcu_node counter that tracks the latest grace period
sought by an earlier task to visit this node.  If that grace period
would satisfy the current task, instead of proceeding up the tree,
it waits on the current rcu_node structure using a pair of wait queues
provided for that purpose.  This decouples awakening of old tasks from
the arrival of new tasks.

If the wakeups prove to be a bottleneck, additional kthreads can be
brought to bear for that purpose.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Add event tracing definitions for expedited grace periods</title>
<updated>2016-03-31T20:34:05Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2016-01-29T04:25:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e087816db9423fdc49302d3cd7ec01e487477a71'/>
<id>urn:sha1:e087816db9423fdc49302d3cd7ec01e487477a71</id>
<content type='text'>
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Apply rcu_seq operations to _rcu_barrier()</title>
<updated>2015-07-17T21:58:57Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2015-06-26T18:20:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4f525a528b9e75571c6bedc6202beff1ced24c32'/>
<id>urn:sha1:4f525a528b9e75571c6bedc6202beff1ced24c32</id>
<content type='text'>
The rcu_seq operations were open-coded in _rcu_barrier(), so this commit
replaces the open-coding with the shiny new rcu_seq operations.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Remove redundant TREE_PREEMPT_RCU config option</title>
<updated>2014-10-29T17:20:05Z</updated>
<author>
<name>Pranith Kumar</name>
</author>
<published>2014-09-22T18:00:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=28f6569ab7d036cd4ee94c26bb76dc1b3f3fc056'/>
<id>urn:sha1:28f6569ab7d036cd4ee94c26bb76dc1b3f3fc056</id>
<content type='text'>
PREEMPT_RCU and TREE_PREEMPT_RCU serve the same function after
TINY_PREEMPT_RCU has been removed. This patch removes TREE_PREEMPT_RCU
and uses PREEMPT_RCU config option in its place.

Signed-off-by: Pranith Kumar &lt;bobby.prani@gmail.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Make rcu_barrier() understand about missing rcuo kthreads</title>
<updated>2014-10-28T20:24:13Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2014-10-27T16:15:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d7e29933969e5ca7c112ce1368a07911f4485dc2'/>
<id>urn:sha1:d7e29933969e5ca7c112ce1368a07911f4485dc2</id>
<content type='text'>
Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs)
avoids creating rcuo kthreads for CPUs that never come online.  This
fixes a bug in many instances of firmware: Instead of lying about their
age, these systems instead lie about the number of CPUs that they have.
Before commit 35ce7f29a44a, this could result in huge numbers of useless
rcuo kthreads being created.

It appears that experience indicates that I should have told the
people suffering from this problem to fix their broken firmware, but
I instead produced what turned out to be a partial fix.   The missing
piece supplied by this commit makes sure that rcu_barrier() knows not to
post callbacks for no-CBs CPUs that have not yet come online, because
otherwise rcu_barrier() will hang on systems having firmware that lies
about the number of CPUs.

It is tempting to simply have rcu_barrier() refuse to post a callback on
any no-CBs CPU that does not have an rcuo kthread.  This unfortunately
does not work because rcu_barrier() is required to wait for all pending
callbacks.  It is therefore required to wait even for those callbacks
that cannot possibly be invoked.  Even if doing so hangs the system.

Given that posting a callback to a no-CBs CPU that does not yet have an
rcuo kthread can hang rcu_barrier(), It is tempting to report an error
in this case.  Unfortunately, this will result in false positives at
boot time, when it is perfectly legal to post callbacks to the boot CPU
before the scheduler has started, in other words, before it is legal
to invoke rcu_barrier().

So this commit instead has rcu_barrier() avoid posting callbacks to
CPUs having neither rcuo kthread nor pending callbacks, and has it
complain bitterly if it finds CPUs having no rcuo kthread but some
pending callbacks.  And when rcu_barrier() does find CPUs having no rcuo
kthread but pending callbacks, as noted earlier, it has no choice but
to hang indefinitely.

Reported-by: Yanko Kaneti &lt;yaneti@declera.com&gt;
Reported-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Reported-by: Meelis Roos &lt;mroos@linux.ee&gt;
Reported-by: Eric B Munson &lt;emunson@akamai.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Eric B Munson &lt;emunson@akamai.com&gt;
Tested-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Tested-by: Yanko Kaneti &lt;yaneti@declera.com&gt;
Tested-by: Kevin Fenzi &lt;kevin@scrye.com&gt;
Tested-by: Meelis Roos &lt;mroos@linux.ee&gt;
</content>
</entry>
<entry>
<title>rcu: Break more call_rcu() deadlock involving scheduler and perf</title>
<updated>2014-09-07T23:18:17Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2014-07-29T21:50:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9fdd3bc9005824704f9802bec7b3e06f5edae434'/>
<id>urn:sha1:9fdd3bc9005824704f9802bec7b3e06f5edae434</id>
<content type='text'>
Commit 96d3fd0d315a9 (rcu: Break call_rcu() deadlock involving scheduler
and perf) covered the case where __call_rcu_nocb_enqueue() needs to wake
the rcuo kthread due to the queue being initially empty, but did not
do anything for the case where the queue was overflowing.  This commit
therefore also defers wakeup for the overflow case.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Avoid sparse warnings in rcu_nocb_wake trace event</title>
<updated>2013-09-23T16:18:17Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2013-08-18T18:59:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=15f5191b6acbbb38029b06284e8fd20275e7cfe8'/>
<id>urn:sha1:15f5191b6acbbb38029b06284e8fd20275e7cfe8</id>
<content type='text'>
The event-tracing macros do not like bool tracing arguments, so this
commit makes them be of type char.  This change has the knock-on effect
of making it illegal to pass a pointer into one of these arguments, so
also change rcutiny's first call to trace_rcu_batch_end() to convert
from pointer to boolean, prefixing with "!!".

Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Track rcu_nocb_kthread()'s sleeping and awakening</title>
<updated>2013-09-23T16:18:16Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2013-08-15T20:23:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=69a79bb12a81024d718e73c52e886907a3777b34'/>
<id>urn:sha1:69a79bb12a81024d718e73c52e886907a3777b34</id>
<content type='text'>
This commit adds event traces to track all of rcu_nocb_kthread()'s
blocking and awakening.

Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
</feed>
