Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1341542 > unrolled thread

[PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
    Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel  CPU-bound workloads as errors Peter Zijlstra <peterz@infradead.org> - 2016-02-25 10:50 +0100
      Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel  CPU-bound workloads as errors "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 18:30 +0100

#1341542 — [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors

Commit 4a81e8328d379 ("Reduce overhead of cond_resched() checks for RCU")
handles the error case where a nohz_full loops indefinitely in the kernel
with the scheduling-clock interrupt disabled.  However, this handling
includes IPIing the CPU running the offending loop, which is not what
we want for real-time workloads.  And there are starting to be real-time
CPU-bound in-kernel workloads, and these must be handled without IPIing
the CPU, at least not in the common case.  Therefore, this situation can
no longer be dismissed as an error case.

This commit therefore splits the handling out, so that the setting of
bits in the per-CPU rcu_sched_qs_mask variable is done relatively early,
but if the problem persists, resched_cpu() is eventually used to IPI the
CPU containing the offending loop.  Assuming that in-kernel CPU-bound
loops used by real-time tasks contain frequent calls cond_resched_rcu_qs()
(as in more than once per few tens of milliseconds), the real-time tasks
will never be IPIed.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/rcu/tree.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a91836868ade..68f4bee3ecc3 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1173,15 +1173,16 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
 			smp_mb(); /* ->cond_resched_completed before *rcrmp. */
 			WRITE_ONCE(*rcrmp,
 				   READ_ONCE(*rcrmp) + rdp->rsp->flavor_mask);
-			resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
-			rdp->rsp->jiffies_resched += 5; /* Enable beating. */
-		} else if (ULONG_CMP_GE(jiffies, rdp->rsp->jiffies_resched)) {
-			/* Time to beat on that CPU again! */
-			resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
-			rdp->rsp->jiffies_resched += 5; /* Re-enable beating. */
 		}
+		rdp->rsp->jiffies_resched += 5; /* Re-enable beating. */
 	}
 
+	/* And if it has been a really long time, kick the CPU as well. */
+	if (ULONG_CMP_GE(jiffies,
+			 rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
+	    ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
+		resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+
 	return 0;
 }
 
-- 
2.5.2

[toc] | [next] | [standalone]

#1343045 — Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors

On Tue, Feb 23, 2016 at 09:12:40PM -0800, Paul E. McKenney wrote:
> Commit 4a81e8328d379 ("Reduce overhead of cond_resched() checks for RCU")
> handles the error case where a nohz_full loops indefinitely in the kernel
> with the scheduling-clock interrupt disabled.  However, this handling
> includes IPIing the CPU running the offending loop, which is not what
> we want for real-time workloads.  And there are starting to be real-time
> CPU-bound in-kernel workloads, and these must be handled without IPIing
> the CPU, at least not in the common case.  Therefore, this situation can
> no longer be dismissed as an error case.

Do explain. Doing "for (;;) ;" in a kernel RT thread is just as bad for
general system health as is doing the same in userspace.

Also, who runs his RT workload in-kernel ?

[toc] | [prev] | [next] | [standalone]

#1343345 — Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors

On Thu, Feb 25, 2016 at 10:43:17AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 23, 2016 at 09:12:40PM -0800, Paul E. McKenney wrote:
> > Commit 4a81e8328d379 ("Reduce overhead of cond_resched() checks for RCU")
> > handles the error case where a nohz_full loops indefinitely in the kernel
> > with the scheduling-clock interrupt disabled.  However, this handling
> > includes IPIing the CPU running the offending loop, which is not what
> > we want for real-time workloads.  And there are starting to be real-time
> > CPU-bound in-kernel workloads, and these must be handled without IPIing
> > the CPU, at least not in the common case.  Therefore, this situation can
> > no longer be dismissed as an error case.
> 
> Do explain. Doing "for (;;) ;" in a kernel RT thread is just as bad for
> general system health as is doing the same in userspace.

The use case is instead something like this:

	for (;;) {
		do_something();
		cond_resched_rcu_qs();
	}

If you instead do something like this:

	for (;;)
		do_something();

where do_something() doesn't invoke cond_resched_rcu_qs() often enough,
then your kernel is broken and the warrantee says that you get to keep
the pieces.

> Also, who runs his RT workload in-kernel ?

That would be me, actually.

I use something very much like this in rcutorture and in rcuperf (the
latter currently exists only in -rcu, although 0day has been helpfully
finding various problems with it).  In rcutorture, the problem never
arises given default kernel-boot-parameter settings.  However, you
could easily set various timing parameters to exceed the RCU CPU stall
warning timeout.

In rcuperf, this sort of thing happens by default under heavy load.

So why bother if the use case is this obscure?

Because I have been getting beaten up repeatedly over the past few years
about RCU sending IPIs, so I figured that this time I should at least
-try- to get ahead of the game!  ;-)

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web