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

Groups > linux.kernel > #1174787 > unrolled thread

[PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

Back to article view | Back to linux.kernel

Contents

  [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging  normal ones "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-30 23:50 +0200
    [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-30 23:50 +0200
      Re: [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to  every 10 ms or every 4th GP Eric Dumazet <edumazet@google.com> - 2015-07-01 00:00 +0200
    [PATCH RFC tip/core/rcu 1/5] rcu: Prepare for expedited GP driving normal GP "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-30 23:50 +0200
    Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods  encouraging normal ones josh@joshtriplett.org - 2015-07-01 00:10 +0200
      Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging  normal ones Josh Triplett <josh@joshtriplett.org> - 2015-07-01 02:50 +0200
      Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods  encouraging normal ones josh@joshtriplett.org - 2015-07-01 23:30 +0200
        Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging  normal ones "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-01 23:50 +0200
      Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods  encouraging normal ones Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-07-02 03:20 +0200
        Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods  encouraging normal ones josh@joshtriplett.org - 2015-07-02 03:40 +0200
          Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods  encouraging normal ones Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-07-02 04:10 +0200

#1174787 — [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

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:

1.	Pure code-movement commit that allows the RCU grace-period kthread
	to access the expedited grace period's state.

2.	Use snapshot technique to allow a normal grace period to complete
	after an expedited grace period has completed.

3.	Changes to rcutorture to fully test normal grace periods.  Current
	tests would fail to notice some types of forward-progress bugs due
	to the presence of expedited grace periods in the common case.

4.	Make expedited grace periods awaken any concurrent normal grace
	periods.

5.	Throttle the awakening to avoid excessive CPU consumption by the
	normal grace-period kthread.

A separate series will cover changes to the expedited grace-period
machinery itself.

							Thanx, Paul

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

 b/kernel/rcu/rcutorture.c |   22 +++++-
 b/kernel/rcu/tree.c       |  165 +++++++++++++++++++++++++++-------------------
 b/kernel/rcu/tree.h       |    6 +
 3 files changed, 127 insertions(+), 66 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1174788 — [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcu/tree.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 308b6acb4260..247aa1120c4c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -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();
 }
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1174792 — Re: [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP

On Tue, Jun 30, 2015 at 11:48 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>  kernel/rcu/tree.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 308b6acb4260..247aa1120c4c 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -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;

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

> +                       wake_up(&rsp->gp_wq);
> +               }
> +       }
> +       mutex_unlock(&rnp->exp_funnel_mutex);
>
>         put_online_cpus();
>  }
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1174789 — [PATCH RFC tip/core/rcu 1/5] rcu: Prepare for expedited GP driving normal GP

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>

This is a pure code-movement commit in preparation for changes that
allow short-circuiting of normal grace-period processing due to
concurrent execution of an expedited grace period.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcu/tree.c | 108 +++++++++++++++++++++++++++---------------------------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 041968e3b7ce..bea9b9c80d91 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1393,6 +1393,60 @@ void rcu_cpu_stall_reset(void)
 		WRITE_ONCE(rsp->jiffies_stall, jiffies + ULONG_MAX / 2);
 }
 
+/* Adjust sequence number for start of update-side operation. */
+static void rcu_seq_start(unsigned long *sp)
+{
+	WRITE_ONCE(*sp, *sp + 1);
+	smp_mb(); /* Ensure update-side operation after counter increment. */
+	WARN_ON_ONCE(!(*sp & 0x1));
+}
+
+/* Adjust sequence number for end of update-side operation. */
+static void rcu_seq_end(unsigned long *sp)
+{
+	smp_mb(); /* Ensure update-side operation before counter increment. */
+	WRITE_ONCE(*sp, *sp + 1);
+	WARN_ON_ONCE(*sp & 0x1);
+}
+
+/* Take a snapshot of the update side's sequence number. */
+static unsigned long rcu_seq_snap(unsigned long *sp)
+{
+	unsigned long s;
+
+	smp_mb(); /* Caller's modifications seen first by other CPUs. */
+	s = (READ_ONCE(*sp) + 3) & ~0x1;
+	smp_mb(); /* Above access must not bleed into critical section. */
+	return s;
+}
+
+/*
+ * Given a snapshot from rcu_seq_snap(), determine whether or not a
+ * full update-side operation has occurred.
+ */
+static bool rcu_seq_done(unsigned long *sp, unsigned long s)
+{
+	return ULONG_CMP_GE(READ_ONCE(*sp), s);
+}
+
+/* Wrapper functions for expedited grace periods.  */
+static void rcu_exp_gp_seq_start(struct rcu_state *rsp)
+{
+	rcu_seq_start(&rsp->expedited_sequence);
+}
+static void rcu_exp_gp_seq_end(struct rcu_state *rsp)
+{
+	rcu_seq_end(&rsp->expedited_sequence);
+}
+static unsigned long rcu_exp_gp_seq_snap(struct rcu_state *rsp)
+{
+	return rcu_seq_snap(&rsp->expedited_sequence);
+}
+static bool rcu_exp_gp_seq_done(struct rcu_state *rsp, unsigned long s)
+{
+	return rcu_seq_done(&rsp->expedited_sequence, s);
+}
+
 /*
  * Initialize the specified rcu_data structure's default callback list
  * to empty.  The default callback list is the one that is not used by
@@ -3307,60 +3361,6 @@ void cond_synchronize_sched(unsigned long oldstate)
 }
 EXPORT_SYMBOL_GPL(cond_synchronize_sched);
 
-/* Adjust sequence number for start of update-side operation. */
-static void rcu_seq_start(unsigned long *sp)
-{
-	WRITE_ONCE(*sp, *sp + 1);
-	smp_mb(); /* Ensure update-side operation after counter increment. */
-	WARN_ON_ONCE(!(*sp & 0x1));
-}
-
-/* Adjust sequence number for end of update-side operation. */
-static void rcu_seq_end(unsigned long *sp)
-{
-	smp_mb(); /* Ensure update-side operation before counter increment. */
-	WRITE_ONCE(*sp, *sp + 1);
-	WARN_ON_ONCE(*sp & 0x1);
-}
-
-/* Take a snapshot of the update side's sequence number. */
-static unsigned long rcu_seq_snap(unsigned long *sp)
-{
-	unsigned long s;
-
-	smp_mb(); /* Caller's modifications seen first by other CPUs. */
-	s = (READ_ONCE(*sp) + 3) & ~0x1;
-	smp_mb(); /* Above access must not bleed into critical section. */
-	return s;
-}
-
-/*
- * Given a snapshot from rcu_seq_snap(), determine whether or not a
- * full update-side operation has occurred.
- */
-static bool rcu_seq_done(unsigned long *sp, unsigned long s)
-{
-	return ULONG_CMP_GE(READ_ONCE(*sp), s);
-}
-
-/* Wrapper functions for expedited grace periods.  */
-static void rcu_exp_gp_seq_start(struct rcu_state *rsp)
-{
-	rcu_seq_start(&rsp->expedited_sequence);
-}
-static void rcu_exp_gp_seq_end(struct rcu_state *rsp)
-{
-	rcu_seq_end(&rsp->expedited_sequence);
-}
-static unsigned long rcu_exp_gp_seq_snap(struct rcu_state *rsp)
-{
-	return rcu_seq_snap(&rsp->expedited_sequence);
-}
-static bool rcu_exp_gp_seq_done(struct rcu_state *rsp, unsigned long s)
-{
-	return rcu_seq_done(&rsp->expedited_sequence, s);
-}
-
 /* Common code for synchronize_{rcu,sched}_expedited() work-done checking. */
 static bool sync_exp_work_done(struct rcu_state *rsp, struct rcu_node *rnp,
 			       atomic_long_t *stat, unsigned long s)
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1174796 — Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> 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).

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1174852

On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 04:46:33PM -0700, josh@joshtriplett.org wrote:
> > On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 30, 2015 at 03:00:15PM -0700, josh@joshtriplett.org wrote:
> > > > On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> > > > > 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).
> > > 
> > > 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.
> 
> > 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?

> 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. :)

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1175556 — Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

On Wed, Jul 01, 2015 at 01:09:36PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > 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.

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.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1175566

On Wed, Jul 01, 2015 at 02:20:01PM -0700, josh@joshtriplett.org wrote:
> On Wed, Jul 01, 2015 at 01:09:36PM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > > 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.
> 
> 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.

So people are really seeing a synchronize_rcu_expedited() on each
container setup/teardown right now?  Or is this something that could
happen if they were mounting block devices rather than rebind mounts?

And when you say that these workloads are sensitive to latency, I am
guessing that you mean to the millisecond-level latencies seen from
synchronize_rcu() as opposed to the microsecond-level OS jitter from
synchronize_rcu_expedited().  Or are there really containers workloads
that care about the few microseconds of OS jitter that would be incurred
due to expedited grace periods?

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1175642 — Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > 
> > > That is a bit extreme, Peter.
> > 
> > Of course; but I'm really not seeing people taking due care with them
> 
> ;-)
> 
> > > 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.

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.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1175645 — Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > > 
> > > > That is a bit extreme, Peter.
> > > 
> > > Of course; but I'm really not seeing people taking due care with them
> > 
> > ;-)
> > 
> > > > 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.
> 
> 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.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1175654 — Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

On Wed, 2015-07-01 at 18:34 -0700, josh@joshtriplett.org wrote:
> On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> > On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > > > 
> > > > > That is a bit extreme, Peter.
> > > > 
> > > > Of course; but I'm really not seeing people taking due care with them
> > > 
> > > ;-)
> > > 
> > > > > 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.
> > 
> > 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.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web