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

From	josh@joshtriplett.org
Newsgroups	linux.kernel
Subject	Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
Date	2015-07-01 23:30 +0200
Message-ID	<pHxJW-23b-65@gated-at.bofh.it> (permalink)
References	(5 earlier) <pHqS6-6ae-17@gated-at.bofh.it> <pHr1L-6fJ-3@gated-at.bofh.it> <pHsTV-7pb-33@gated-at.bofh.it> <pHtGi-7Wq-15@gated-at.bofh.it> <pHx7b-1sY-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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/

Thread

[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

csiph-web