Expedited grace periods encouraging normal ones

kernel/rcu/tree.c +0 -2

@@ -2121,17 +2137,24 @@ static int __noreturn rcu_gp_kthread(void *arg)
 					       TPS("fqswait"));
 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
-					((gf = READ_ONCE(rsp->gp_flags)) &
-					 RCU_GP_FLAG_FQS) ||

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +1 -5

@@ -2121,17 +2137,24 @@ static int __noreturn rcu_gp_kthread(void *arg)
 					       TPS("fqswait"));
 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
-					((gf = READ_ONCE(rsp->gp_flags)) &
-					 RCU_GP_FLAG_FQS) ||
-					(!READ_ONCE(rnp->qsmask) &&
-					 !rcu_preempt_blocked_readers_cgp(rnp)),
-					j);
+				((gf = READ_ONCE(rsp->gp_flags)) &

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2146

Quoted 6 lines

kernel/rcu/tree.c +6 -0

+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);

How about using a helper function there?

static inline bool rcu_gp_done(rsp, rnp)

{
	/* Forced Quiescent State complete */
	if (READ_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS)
		return true;

	/* QS not masked and not blocked by preempted readers */
	if (!READ_ONCE(rnp->qsmask) &&
	    !rcu_preempt_blocked_readers_cgp(rnp))
		return true;

	/* Expedited Grace Period completed */
	if (rcu_exp_gp_seq_done(rsp))
		return true;

	return false;
}

	ret = wait_event_interruptible_timeout(rsp->gp_wq,
		rcu_gp_done(rsp, rnp), j);

Quoted 6 lines · Paul E. McKenney

(quoted diff) +0 -2

@@ -2121,17 +2137,24 @@ static int __noreturn rcu_gp_kthread(void *arg)
 					       TPS("fqswait"));
 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
-					((gf = READ_ONCE(rsp->gp_flags)) &
-					 RCU_GP_FLAG_FQS) ||

Review static int __noreturn rcu_gp_kthread(void *arg) · line 2146

Quoted 10 lines

(quoted diff) +7 -3

-					(!READ_ONCE(rnp->qsmask) &&
-					 !rcu_preempt_blocked_readers_cgp(rnp)),
-					j);
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);

How about using a helper function there?

static inline bool rcu_gp_done(rsp, rnp)

{
	/* Forced Quiescent State complete */
	if (READ_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS)
		return true;

	/* QS not masked and not blocked by preempted readers */
	if (!READ_ONCE(rnp->qsmask) &&
	    !rcu_preempt_blocked_readers_cgp(rnp))
		return true;

	/* Expedited Grace Period completed */
	if (rcu_exp_gp_seq_done(rsp))
		return true;

	return false;
}

	ret = wait_event_interruptible_timeout(rsp->gp_wq,
		rcu_gp_done(rsp, rnp), j);

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2147

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +7 -0

 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);
 			rsp->gp_state = RCU_GP_DONE_FQS;

How can the GP be done if we timed out or got interrupted?

Quoted 13 lines · Peter Zijlstra

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2147

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +7 -0

 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);
 			rsp->gp_state = RCU_GP_DONE_FQS;

How can the GP be done if we timed out or got interrupted?

If all the CPUs still blocking the grace period went idle, or in a NO_HZ_FULL kernel, entered nohz_full userspace execution. Or, if certain low-probability races happen, went offline.

Quoted 15 lines · Paul E. McKenney

Quoted 13 lines · Peter Zijlstra

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2147

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +7 -0

 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);
 			rsp->gp_state = RCU_GP_DONE_FQS;

How can the GP be done if we timed out or got interrupted?

Quoted 3 lines

If all the CPUs still blocking the grace period went idle, or in a NO_HZ_FULL kernel, entered nohz_full userspace execution. Or, if certain low-probability races happen, went offline.

But what if none of those are true and we still timed out? You unconditionally grant the GP.

Quoted 16 lines · Peter Zijlstra

Quoted 15 lines · Paul E. McKenney

Quoted 13 lines · Peter Zijlstra

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2147

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +7 -0

 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);
 			rsp->gp_state = RCU_GP_DONE_FQS;

How can the GP be done if we timed out or got interrupted?

Quoted 6 lines

Quoted 3 lines

If all the CPUs still blocking the grace period went idle, or in a NO_HZ_FULL kernel, entered nohz_full userspace execution. Or, if certain low-probability races happen, went offline.

But what if none of those are true and we still timed out? You unconditionally grant the GP.

Say what???

I recheck the conditions and break out of the loop only if one or more of the grace-period-end conditions is satisfied. If not, I invoke rcu_gp_fqs() to do the scan to see if all remaining CPUs are idle, in nohz_full userspace execution, or offline.

What am I mising here?

Quoted 31 lines · Paul E. McKenney

Quoted 16 lines · Peter Zijlstra

Quoted 15 lines · Paul E. McKenney

Quoted 13 lines · Peter Zijlstra

kernel/rcu/tree.c static int __noreturn rcu_gp_kthread(void *arg) · line 2147

Quoted 10 lines · Paul E. McKenney

kernel/rcu/tree.c +7 -0

 			rsp->gp_state = RCU_GP_WAIT_FQS;
 			ret = wait_event_interruptible_timeout(rsp->gp_wq,
+				((gf = READ_ONCE(rsp->gp_flags)) &
+				 RCU_GP_FLAG_FQS) ||
+				(!READ_ONCE(rnp->qsmask) &&
+				 !rcu_preempt_blocked_readers_cgp(rnp)) ||
+				rcu_exp_gp_seq_done(rsp->exp_rsp,
+						    rsp->gp_exp_snap),
+				j);
 			rsp->gp_state = RCU_GP_DONE_FQS;

How can the GP be done if we timed out or got interrupted?

Quoted 6 lines

Quoted 3 lines

If all the CPUs still blocking the grace period went idle, or in a NO_HZ_FULL kernel, entered nohz_full userspace execution. Or, if certain low-probability races happen, went offline.

But what if none of those are true and we still timed out? You unconditionally grant the GP.

Say what???

I recheck the conditions and break out of the loop only if one or more of the grace-period-end conditions is satisfied. If not, I invoke rcu_gp_fqs() to do the scan to see if all remaining CPUs are idle, in nohz_full userspace execution, or offline.

Quoted 1 line

What am I mising here?

The whole wait_event_interruptible_timeout() thing can end without @cond being true, after which you unconditionally set ->gp_state = RCU_GP_DONE_FQS.

Or is your point that RCU_GP_DONE_FQS is a bad name? Perhaps I should change it to something like RCU_GP_DOING_FQS. Or am I still missing something here?

Quoted 3 lines · Paul E. McKenney

Or is your point that RCU_GP_DONE_FQS is a bad name? Perhaps I should change it to something like RCU_GP_DOING_FQS. Or am I still missing something here?

Yes, that might have been the root of my confusion.

OK, how about this, then?

rcu: Rename RCU_GP_DONE_FQS to RCU_GP_DOING_FQS

The grace-period kthread sleeps waiting to do a force-quiescent-state scan, and when awakened sets rsp->gp_state to RCU_GP_DONE_FQS. However, this is confusing because the kthread has not done the force-quiescent-state, but is instead just starting to do it. This commit therefore renames RCU_GP_DONE_FQS to RCU_GP_DOING_FQS in order to make things a bit easier on reviewers.

Reported-by Peter Zijlstra <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

From: "Paul E. McKenney" <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

kernel/rcu/tree.c +0 -1

index 308b6acb4260..247aa1120c4c 100644
@@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
                           !atomic_read(&rsp->expedited_need_qs));
 
        rcu_exp_gp_seq_end(rsp);
-       mutex_unlock(&rnp->exp_funnel_mutex);
        smp_mb(); /* ensure subsequent action seen after grace period. */

kernel/rcu/tree.c +4 -1

+                       wake_up(&rsp->gp_wq);
+               }
+       }
+       mutex_unlock(&rnp->exp_funnel_mutex);
 
        put_online_cpus();
 }
--

1.8.1.5

Quoted 14 lines · Paul E. McKenney

From: "Paul E. McKenney" <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

kernel/rcu/tree.c +0 -0

index 308b6acb4260..247aa1120c4c 100644
@@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
                           !atomic_read(&rsp->expedited_need_qs));
 

kernel/rcu/tree.c void synchronize_sched_expedited(void) · line 3516

Quoted 13 lines

kernel/rcu/tree.c +8 -3

        rcu_exp_gp_seq_end(rsp);
-       mutex_unlock(&rnp->exp_funnel_mutex);
        smp_mb(); /* ensure subsequent action seen after grace period. */
-       if (rsp->gp_kthread && rcu_gp_in_progress(rsp))
-               wake_up(&rsp->gp_wq);
+       if (rsp->gp_kthread && rcu_gp_in_progress(rsp)) {
+               static unsigned long nextgp;
+               static unsigned long nextjiffy;
+
+               if (time_after_eq(jiffies, nextgp) ||
+                   ULONG_CMP_GE(rsp->gpnum, nextgp)) {
+                       nextgp = rsp->gpnum + 4;
+                       nextjiffy = jiffies + 10;

Do you want 10 ticks or 10 ms (as stated in title) ?

Quoted 10 lines

kernel/rcu/tree.c +4 -1

+                       wake_up(&rsp->gp_wq);
+               }
+       }
+       mutex_unlock(&rnp->exp_funnel_mutex);
 
        put_online_cpus();
 }
--

1.8.1.5

From: "Paul E. McKenney" <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

kernel/rcu/tree.c +12 -3

index 308b6acb4260..247aa1120c4c 100644
@@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
 			   !atomic_read(&rsp->expedited_need_qs));
 
 	rcu_exp_gp_seq_end(rsp);
-	mutex_unlock(&rnp->exp_funnel_mutex);
 	smp_mb(); /* ensure subsequent action seen after grace period. */
-	if (rsp->gp_kthread && rcu_gp_in_progress(rsp))
-		wake_up(&rsp->gp_wq);
+	if (rsp->gp_kthread && rcu_gp_in_progress(rsp)) {
+		static unsigned long nextgp;
+		static unsigned long nextjiffy;
+
+		if (time_after_eq(jiffies, nextgp) ||
+		    ULONG_CMP_GE(rsp->gpnum, nextgp)) {
+			nextgp = rsp->gpnum + 4;
+			nextjiffy = jiffies + 10;
+			wake_up(&rsp->gp_wq);
+		}
+	}
+	mutex_unlock(&rnp->exp_funnel_mutex);
 
 	put_online_cpus();
 }

Signature · 1 line

1.8.1.5

Quoted 1 line · Paul E. McKenney

From: "Paul E. McKenney" <[email protected]>

This seems like a good place to explain why this is a desirable thing, no?

Why would you want to limit this?

Quoted 35 lines

Signed-off-by Paul E. McKenney <[email protected]>

---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

kernel/rcu/tree.c +12 -3

index 308b6acb4260..247aa1120c4c 100644
@@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
 			   !atomic_read(&rsp->expedited_need_qs));
 
 	rcu_exp_gp_seq_end(rsp);
-	mutex_unlock(&rnp->exp_funnel_mutex);
 	smp_mb(); /* ensure subsequent action seen after grace period. */
-	if (rsp->gp_kthread && rcu_gp_in_progress(rsp))
-		wake_up(&rsp->gp_wq);
+	if (rsp->gp_kthread && rcu_gp_in_progress(rsp)) {
+		static unsigned long nextgp;
+		static unsigned long nextjiffy;
+
+		if (time_after_eq(jiffies, nextgp) ||
+		    ULONG_CMP_GE(rsp->gpnum, nextgp)) {
+			nextgp = rsp->gpnum + 4;
+			nextjiffy = jiffies + 10;
+			wake_up(&rsp->gp_wq);
+		}
+	}
+	mutex_unlock(&rnp->exp_funnel_mutex);
 
 	put_online_cpus();
 }

Signature · 1 line

1.8.1.5

Quoted 1 line · Paul E. McKenney

From: "Paul E. McKenney" <[email protected]>

This seems like a good place to explain why this is a desirable thing, no?

Why would you want to limit this?

Quoted 35 lines

Signed-off-by Paul E. McKenney <[email protected]>

---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

kernel/rcu/tree.c +12 -3

index 308b6acb4260..247aa1120c4c 100644
@@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
 			   !atomic_read(&rsp->expedited_need_qs));
 
 	rcu_exp_gp_seq_end(rsp);
-	mutex_unlock(&rnp->exp_funnel_mutex);
 	smp_mb(); /* ensure subsequent action seen after grace period. */
-	if (rsp->gp_kthread && rcu_gp_in_progress(rsp))
-		wake_up(&rsp->gp_wq);
+	if (rsp->gp_kthread && rcu_gp_in_progress(rsp)) {
+		static unsigned long nextgp;
+		static unsigned long nextjiffy;
+
+		if (time_after_eq(jiffies, nextgp) ||
+		    ULONG_CMP_GE(rsp->gpnum, nextgp)) {
+			nextgp = rsp->gpnum + 4;
+			nextjiffy = jiffies + 10;
+			wake_up(&rsp->gp_wq);
+		}
+	}
+	mutex_unlock(&rnp->exp_funnel_mutex);
 
 	put_online_cpus();
 }

Signature · 1 line

1.8.1.5

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 11 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

Quoted 10 lines

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Quoted 23 lines · Paul E. McKenney

Quoted 11 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

Quoted 10 lines

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 2 lines

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

From what I can see, this one needs a good reason to go in, as opposed

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Quoted 24 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Quoted 23 lines · Paul E. McKenney

Quoted 21 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 8 lines

Quoted 2 lines

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

From what I can see, this one needs a good reason to go in, as opposed to a good reason to stay out.

Quoted 2 lines

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Networking uses expedited grace periods when RTNL is held to reduce contention on that lock.

Several other places have used it to minimize
user-visible grace-period slowdown. But there are probably places that would be better served doing something different. That is after all the common case for most synchronization primitives. ;-)

Quoted 37 lines · Paul E. McKenney

Quoted 24 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Quoted 23 lines · Paul E. McKenney

Quoted 21 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 8 lines

Quoted 2 lines

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

From what I can see, this one needs a good reason to go in, as opposed to a good reason to stay out.

Quoted 5 lines

Quoted 2 lines

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Networking uses expedited grace periods when RTNL is held to reduce contention on that lock.

Wait, what? Why is anything using traditional (non-S) RCU while *any* lock is held?

Quoted 4 lines

Several other places have used it to minimize
user-visible grace-period slowdown. But there are probably places that would be better served doing something different. That is after all the common case for most synchronization primitives. ;-)

Sounds likely. :)

Quoted 2 lines

Wait, what? Why is anything using traditional (non-S) RCU while *any* lock is held?

In their defense, it is a sleeplock that is never taken except when rearranging networking configuration. Sometimes they need a grace period under the lock. So synchronize_net() checks to see if RTNL is held, and does a synchronize_rcu_expedited() if so and a synchronize_rcu() if not.

Quoted 7 lines · Paul E. McKenney

Quoted 2 lines

Wait, what? Why is anything using traditional (non-S) RCU while *any* lock is held?

In their defense, it is a sleeplock that is never taken except when rearranging networking configuration. Sometimes they need a grace period under the lock. So synchronize_net() checks to see if RTNL is held, and does a synchronize_rcu_expedited() if so and a synchronize_rcu() if not.

Sounds vile.

OK, I'll bite. Exactly what seems especially vile about it?

Quoted 1 line

OK, I'll bite. Exactly what seems especially vile about it?

Presumably we would need to convert everything to async model (call_rcu() and friends),
but that is a long way to go...

For example, synchronize_srcu_expedited() in kvm_set_irq_routing() really looks overkill.

Quoted 38 lines · Josh Triplett

Quoted 37 lines · Paul E. McKenney

Quoted 24 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Quoted 23 lines · Paul E. McKenney

Quoted 21 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 8 lines

Quoted 2 lines

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

From what I can see, this one needs a good reason to go in, as opposed to a good reason to stay out.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Networking uses expedited grace periods when RTNL is held to reduce contention on that lock.

Wait, what? Why is anything using traditional (non-S) RCU while *any* lock is held?

In their defense, it is a sleeplock that is never taken except when rearranging networking configuration. Sometimes they need a grace period under the lock. So synchronize_net() checks to see if RTNL is held, and does a synchronize_rcu_expedited() if so and a synchronize_rcu() if not.

But maybe I am misunderstanding your question?

Quoted 53 lines · Paul E. McKenney

Quoted 38 lines · Josh Triplett

Quoted 37 lines · Paul E. McKenney

Quoted 24 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Quoted 23 lines · Paul E. McKenney

Quoted 21 lines · On Tue, Jun 30, 2015 at 03:00:15PM -0700, [email protected] wrote:

Quoted 9 lines · Paul E. McKenney

Hello!

This series contains some highly experimental patches that allow normal grace periods to take advantage of the work done by concurrent expedited grace periods. This can reduce the overhead incurred by normal grace periods by eliminating the need for force-quiescent-state scans that would otherwise have happened after the expedited grace period completed. It is not clear whether this is a useful tradeoff. Nevertheless, this series contains the following patches:

While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second).

Quoted 8 lines

Quoted 2 lines

I will take that as another vote against. And for a reason that I had not yet come up with, so good show! ;-)

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

From what I can see, this one needs a good reason to go in, as opposed to a good reason to stay out.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Networking uses expedited grace periods when RTNL is held to reduce contention on that lock.

Wait, what? Why is anything using traditional (non-S) RCU while *any* lock is held?

In their defense, it is a sleeplock that is never taken except when rearranging networking configuration. Sometimes they need a grace period under the lock. So synchronize_net() checks to see if RTNL is held, and does a synchronize_rcu_expedited() if so and a synchronize_rcu() if not.

Quoted 1 line

But maybe I am misunderstanding your question?

No, you understood my question. It seems wrong that they would need a grace period *under* the lock, rather than the usual case of making a change under the lock, dropping the lock, and *then* synchronizing.

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

Then again, perhaps the more relevant concern would be why drivers use expedited grace periods in the first place.

Quoted 5 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

random drivers, or for that matter, new-code of any sort. Should _NOT_ be using expedited grace periods.

They're a horrid hack only suitable for unfixable ABI.

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · On Tue, Jun 30, 2015 at 04:46:33PM -0700, [email protected] wrote:

Consider it a fairly weak concern against. Increasing performance seems like a good thing in general; I just don't relish the future "feels less responsive" bug reports that take a long time to track down and turn out to be "this completely unrelated driver was loaded and started using expedited grace periods".

Quoted 4 lines

random drivers, or for that matter, new-code of any sort. Should _NOT_ be using expedited grace periods.

They're a horrid hack only suitable for unfixable ABI.

Let me repeat, just in case I've not been clear. Expedited grace periods are _BAD_ and should be avoided at all costs.

They perturb the _entire_ machine.

Yes we can polish the turd, but in the end its still a turd.

Sadly people seem to have taken a liking to them, ooh a make RCU go faster button. And there's not been much if any pushback on people using it.

That is a bit extreme, Peter.

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

Quoted 1 line · Paul E. McKenney

That is a bit extreme, Peter.

Of course; but I'm really not seeing people taking due care with them

Quoted 2 lines

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

This is complete horse manure (breaking the nvidiot binary blob is a good thing):

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Also, I'm not entirely convinced things like:

fd2ed4d25270 ("dm: add statistics support")
83d5e5b0af90 ("dm: optimize use SRCU and RCU")
ef3230880abd ("backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu")

Are in the 'never' happens category. Esp. the backing-dev one, it triggers every time you unplug a USB stick or similar.

Rejigging a DM might indeed be rare enough; but then again, people use DM explicitly so they can rejig while in operation.

Also, they really do not explain how expedited really is the only option available. Why things can't be batched etc..

Quoted 1 line · Peter Zijlstra

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs. And any runtime use of ACPI as well. And let's face it, if your latency-sensitive workload is using either binary blobs or ACPI, you have already completely lost. Therefore, an additional expedited grace period cannot possibly cause you to lose any more.

Quoted 8 lines

Also, I'm not entirely convinced things like:

fd2ed4d25270 ("dm: add statistics support")
83d5e5b0af90 ("dm: optimize use SRCU and RCU")
ef3230880abd ("backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu")

Are in the 'never' happens category. Esp. the backing-dev one, it triggers every time you unplug a USB stick or similar.

Which people should be assiduously avoiding for any sort of industrial-control system, especially given things like STUXNET.

Quoted 2 lines

Rejigging a DM might indeed be rare enough; but then again, people use DM explicitly so they can rejig while in operation.

They rejig DM when running OS-jitter-sensitive workloads?

Quoted 4 lines · Paul E. McKenney

Quoted 1 line · Peter Zijlstra

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Quoted 8 lines

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs. And any runtime use of ACPI as well. And let's face it, if your latency-sensitive workload is using either binary blobs or ACPI, you have already completely lost. Therefore, an additional expedited grace period cannot possibly cause you to lose any more.

This isn't solely about rt etc.. this call is a generic facility used by however many consumers. A normal workstation/server could run into it at relatively high frequency depending on its workload.

Even on not latency sensitive workloads I think hammering all active CPUs is bad behaviour. Remember that a typical server class machine easily has more than 32 CPUs these days.

Quoted 11 lines

Quoted 8 lines

Also, I'm not entirely convinced things like:

fd2ed4d25270 ("dm: add statistics support")
83d5e5b0af90 ("dm: optimize use SRCU and RCU")
ef3230880abd ("backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu")

Are in the 'never' happens category. Esp. the backing-dev one, it triggers every time you unplug a USB stick or similar.

Which people should be assiduously avoiding for any sort of industrial-control system, especially given things like STUXNET.

USB sure, but a backing dev is involved in nfs clients, loopback and all sorts of block/filesystem like setups.

unmount an NFS mount and voila expedited rcu, unmount a loopback, tada.

All you need is a regular server workload triggering any of that on a semi regular basis and even !rt people might start to notice something is up.

Quoted 4 lines

Quoted 2 lines

Rejigging a DM might indeed be rare enough; but then again, people use DM explicitly so they can rejig while in operation.

They rejig DM when running OS-jitter-sensitive workloads?

Unlikely but who knows, I don't really know DM, so I can't even tell what would trigger these.

Quoted 8 lines · Peter Zijlstra

USB sure, but a backing dev is involved in nfs clients, loopback and all sorts of block/filesystem like setups.

unmount an NFS mount and voila expedited rcu, unmount a loopback, tada.

All you need is a regular server workload triggering any of that on a semi regular basis and even !rt people might start to notice something is up.

I don't believe that latency-sensitive systems are going to be messing with remapping their storage at runtime, let alone on a regular basis. If they are not latency sensitive, and assuming that the rate of storage remapping is at all sane, I bet that they won't notice the synchronize_rcu_expedited() overhead. The overhead of the actual remapping will very likely leave the synchronize_rcu_expedited() overhead way down in the noise.

And if they are doing completely insane rates of storage remapping, I suspect that the batching in the synchronize_rcu_expedited() implementation will reduce the expedited-grace-period overhead still further as a fraction of the total.

Quoted 18 lines · Paul E. McKenney

Quoted 8 lines · Peter Zijlstra

USB sure, but a backing dev is involved in nfs clients, loopback and all sorts of block/filesystem like setups.

unmount an NFS mount and voila expedited rcu, unmount a loopback, tada.

All you need is a regular server workload triggering any of that on a semi regular basis and even !rt people might start to notice something is up.

I don't believe that latency-sensitive systems are going to be messing with remapping their storage at runtime, let alone on a regular basis. If they are not latency sensitive, and assuming that the rate of storage remapping is at all sane, I bet that they won't notice the synchronize_rcu_expedited() overhead. The overhead of the actual remapping will very likely leave the synchronize_rcu_expedited() overhead way down in the noise.

Quoted 4 lines

And if they are doing completely insane rates of storage remapping, I suspect that the batching in the synchronize_rcu_expedited() implementation will reduce the expedited-grace-period overhead still further as a fraction of the total.

Consider the case of container-based systems, calling mount as part of container setup and umount as part of container teardown.

And those workloads are often sensitive to latency, not throughput.

Quoted 18 lines · Peter Zijlstra

Quoted 4 lines · Paul E. McKenney

Quoted 1 line · Peter Zijlstra

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Quoted 8 lines

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs. And any runtime use of ACPI as well. And let's face it, if your latency-sensitive workload is using either binary blobs or ACPI, you have already completely lost. Therefore, an additional expedited grace period cannot possibly cause you to lose any more.

This isn't solely about rt etc.. this call is a generic facility used by however many consumers. A normal workstation/server could run into it at relatively high frequency depending on its workload.

Quoted 3 lines

Even on not latency sensitive workloads I think hammering all active CPUs is bad behaviour. Remember that a typical server class machine easily has more than 32 CPUs these days.

Well, that certainly is one reason for the funnel locking, sequence counters, etc., keeping the overhead bounded despite large numbers of CPUs. So I don't believe that a non-RT/non-HPC workload is going to notice.

Quoted 19 lines · Paul E. McKenney

Quoted 18 lines · Peter Zijlstra

Quoted 4 lines · Paul E. McKenney

Quoted 1 line · Peter Zijlstra

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Quoted 8 lines

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs. And any runtime use of ACPI as well. And let's face it, if your latency-sensitive workload is using either binary blobs or ACPI, you have already completely lost. Therefore, an additional expedited grace period cannot possibly cause you to lose any more.

This isn't solely about rt etc.. this call is a generic facility used by however many consumers. A normal workstation/server could run into it at relatively high frequency depending on its workload.

Quoted 7 lines

Quoted 3 lines

Even on not latency sensitive workloads I think hammering all active CPUs is bad behaviour. Remember that a typical server class machine easily has more than 32 CPUs these days.

Well, that certainly is one reason for the funnel locking, sequence counters, etc., keeping the overhead bounded despite large numbers of CPUs. So I don't believe that a non-RT/non-HPC workload is going to notice.

So I think Peter's concern is that we should not be offering/promoting APIs that are easy to add, hard to remove/convert - especially if we _know_ they eventually have to be converted. That model does not scale, it piles up increasing amounts of crud.

Also, there will be a threshold over which it will be increasingly harder to make hard-rt promises, because so much seemingly mundane functionality will be using these APIs. The big plus of -rt is that it's out of the box hard RT - if people are able to control their environment carefully they can use RTAI or so. I.e. it directly cuts into the usability of Linux in certain segments.

Death by a thousand cuts and such.

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

Quoted 2 lines

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

OK, first let me make sure that I understand what you are asking for:

1. Completely eliminate synchronize_rcu_expedited() and
synchronize_sched_expedited(), replacing all uses with their unexpedited counterparts. (Note that synchronize_srcu_expedited() does not wake up CPUs, courtesy of its read-side memory barriers.) The fast-boot guys are probably going to complain, along with the networking guys.

2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
but push back hard on any new uses and question any existing uses.

3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in

	acpi_os_map_cleanup").

4. Something else?

Quoted 15 lines · Paul E. McKenney

Quoted 2 lines

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

OK, first let me make sure that I understand what you are asking for:

1. Completely eliminate synchronize_rcu_expedited() and
synchronize_sched_expedited(), replacing all uses with their unexpedited counterparts. (Note that synchronize_srcu_expedited() does not wake up CPUs, courtesy of its read-side memory barriers.) The fast-boot guys are probably going to complain, along with the networking guys.

2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
but push back hard on any new uses and question any existing uses.

Quoted 4 lines

3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in

	acpi_os_map_cleanup").

4. Something else?

I'd love to have 1) but 2) would be a realistic second best option? ;-)

Quoted 22 lines · ----- On Jul 2, 2015, at 2:35 PM, Ingo Molnar [email protected] wrote:

Quoted 19 lines · Paul E. McKenney

Quoted 2 lines

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

OK, first let me make sure that I understand what you are asking for:

1. Completely eliminate synchronize_rcu_expedited() and
synchronize_sched_expedited(), replacing all uses with their unexpedited counterparts. (Note that synchronize_srcu_expedited() does not wake up CPUs, courtesy of its read-side memory barriers.) The fast-boot guys are probably going to complain, along with the networking guys.

2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
but push back hard on any new uses and question any existing uses.

3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in

	acpi_os_map_cleanup").

4. Something else?

Quoted 1 line

I'd love to have 1) but 2) would be a realistic second best option? ;-)

Perhaps triggering a printk warning if use of synchronize_{rcu,sched}_expedited() go beyond of certain rate might be another option ? If we detect that a caller calls it too often, we could emit a printk warning with a stack trace. This should ensure everyone is very careful about where they use it.

Quoted 24 lines · Mathieu Desnoyers

Quoted 22 lines · ----- On Jul 2, 2015, at 2:35 PM, Ingo Molnar [email protected] wrote:

Quoted 19 lines · Paul E. McKenney

Quoted 2 lines

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

OK, first let me make sure that I understand what you are asking for:

1. Completely eliminate synchronize_rcu_expedited() and
synchronize_sched_expedited(), replacing all uses with their unexpedited counterparts. (Note that synchronize_srcu_expedited() does not wake up CPUs, courtesy of its read-side memory barriers.) The fast-boot guys are probably going to complain, along with the networking guys.

2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
but push back hard on any new uses and question any existing uses.

3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in

	acpi_os_map_cleanup").

4. Something else?

Quoted 7 lines

Quoted 1 line

I'd love to have 1) but 2) would be a realistic second best option? ;-)

Perhaps triggering a printk warning if use of synchronize_{rcu,sched}_expedited() go beyond of certain rate might be another option ? If we detect that a caller calls it too often, we could emit a printk warning with a stack trace. This should ensure everyone is very careful about where they use it.

My first thought is that a storm of expedited grace periods would be most likely to show up in some error condition, and having them splat might obscure the splats identifying the real problem. Or did you have something else in mind here?

Quoted 15 lines · Paul E. McKenney

Quoted 2 lines

And it's not like it's that hard to stem the flow of algorithmic sloppiness at the source, right?

OK, first let me make sure that I understand what you are asking for:

1. Completely eliminate synchronize_rcu_expedited() and
synchronize_sched_expedited(), replacing all uses with their unexpedited counterparts. (Note that synchronize_srcu_expedited() does not wake up CPUs, courtesy of its read-side memory barriers.) The fast-boot guys are probably going to complain, along with the networking guys.

2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
but push back hard on any new uses and question any existing uses.

Quoted 4 lines

3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in

	acpi_os_map_cleanup").

4. Something else?

I'd love to have 1) but 2) would be a realistic second best option? ;-)

Quoted 5 lines · Peter Zijlstra

Quoted 1 line · Paul E. McKenney

That is a bit extreme, Peter.

Of course; but I'm really not seeing people taking due care with them

;-)

Quoted 6 lines

Quoted 2 lines

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

This is complete horse manure (breaking the nvidiot binary blob is a good thing):

Quoted 1 line

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs.

Quoted 17 lines · Paul E. McKenney

Quoted 5 lines · Peter Zijlstra

Quoted 1 line · Paul E. McKenney

That is a bit extreme, Peter.

Of course; but I'm really not seeing people taking due care with them

;-)

Quoted 7 lines

Quoted 2 lines

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

This is complete horse manure (breaking the nvidiot binary blob is a good thing):

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Quoted 5 lines

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs.

I know two users who have no choice but to use the nvidia driver with their realtime applications, as nouveau is not up to the task.

Quoted 20 lines · Mike Galbraith

Quoted 19 lines · Paul E. McKenney

Quoted 5 lines · Peter Zijlstra

Quoted 1 line · Paul E. McKenney

That is a bit extreme, Peter.

Of course; but I'm really not seeing people taking due care with them

;-)

Quoted 7 lines

Quoted 2 lines

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

This is complete horse manure (breaking the nvidiot binary blob is a good thing):

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Really???

Quoted 6 lines

Quoted 3 lines

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs.

I know two users who have no choice but to use the nvidia driver with their realtime applications, as nouveau is not up to the task.

Sounds like they have a relatively loose definition of "realtime", then.

Quoted 25 lines · On Wed, 2015-07-01 at 18:34 -0700, [email protected] wrote:

Quoted 24 lines · Mike Galbraith

Quoted 22 lines · Paul E. McKenney

Quoted 5 lines · Peter Zijlstra

Quoted 1 line · Paul E. McKenney

That is a bit extreme, Peter.

Of course; but I'm really not seeing people taking due care with them

;-)

Quoted 7 lines

Quoted 2 lines

Are a huge pile of them coming in this merge window or something? What raised your concerns on this issue?

This is complete horse manure (breaking the nvidiot binary blob is a good thing):

74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")

Really???

I am not concerned about this one. After all, one of the first things that people do for OS-jitter-sensitive workloads is to get rid of binary blobs.

Quoted 4 lines

Quoted 2 lines

I know two users who have no choice but to use the nvidia driver with their realtime applications, as nouveau is not up to the task.

Sounds like they have a relatively loose definition of "realtime", then.

It would be better it they broke their beasts up into a bunch of small synchronized boxen, but they use big boxen here and now, with realtime rendering being a non-disposable portion of the load.

Does their normal workload trigger the condition that results in the expedited grace period? If so, do they use NO_HZ_FULL?

Quoted 2 lines · Paul E. McKenney

Does their normal workload trigger the condition that results in the expedited grace period? If so, do they use NO_HZ_FULL?

They're having no trouble that I'm aware of, and I definitely would be made aware. They're not currently using a kernel with NO_HZ_FULL even built in, as that stuff is far far too raw in the current kernel.

They may meet a NO_HZ_FULL enabled kernel soonish, but will be told to not turn it on for anything other than pure compute, as NO_HZ_FULL is currently not usable for mixed load in partitioned box, much less rt.