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

Groups > linux.kernel > #1622352 > unrolled thread

[PATCH tip/core/rcu 0/13] Miscellaneous fixes for 4.12

Started by"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
First post2017-04-12 19:00 +0200
Last post2017-04-19 19:00 +0200
Articles 20 on this page of 85 — 8 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
      Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 11:20 +0200
        Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 18:10 +0200
          Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 18:30 +0200
            Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 19:00 +0200
              Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 19:10 +0200
                Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 19:40 +0200
                  Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 19:50 +0200
                    Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 20:20 +0200
                      Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 20:30 +0200
                        Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 20:50 +0200
                          Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-19 15:30 +0200
                            Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-19 15:50 +0200
                              Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 17:10 +0200
                                Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-19 17:50 +0200
                                  Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:20 +0200
                            Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 17:00 +0200
                  Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick Peter Zijlstra <peterz@infradead.org> - 2017-04-13 20:40 +0200
                    Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text  more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 21:50 +0200
    [PATCH tip/core/rcu 13/13] rcu: Fix typo in PER_RCU_NODE_PERIOD header comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 09/13] mm: Use static initialization for "srcu" "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 12/13] rcu: Use true/false in assignment to bool "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 05/13] rcu: Remove obsolete comment from rcu_future_gp_cleanup() header "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 03/13] types: Update obsolete callback_head comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 11/13] rcu: Use bool value directly "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 10/13] torture: Use correct path for Kconfig fragment for duplicates "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 02/13] lockdep: Use "WARNING" tag on lockdep splats "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
      Re: [PATCH tip/core/rcu 02/13] lockdep: Use "WARNING" tag on lockdep  splats Peter Zijlstra <peterz@infradead.org> - 2017-04-13 11:20 +0200
        Re: [PATCH tip/core/rcu 02/13] lockdep: Use "WARNING" tag on lockdep  splats "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 18:10 +0200
    [PATCH tip/core/rcu 06/13] hlist_add_tail_rcu disable sparse warning "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:00 +0200
    [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-12 19:10 +0200
      Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU Peter Zijlstra <peterz@infradead.org> - 2017-04-13 11:20 +0200
        Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU Vlastimil Babka <vbabka@suse.cz> - 2017-04-13 13:10 +0200
          Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 18:10 +0200
          Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU Peter Zijlstra <peterz@infradead.org> - 2017-04-13 18:20 +0200
            Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-13 19:30 +0200
            Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU Eric Dumazet <edumazet@google.com> - 2017-04-13 23:40 +0200
              Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU Peter Zijlstra <peterz@infradead.org> - 2017-04-14 10:50 +0200
                Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-14 15:50 +0200
    [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:30 +0200
      [PATCH v2 tip/core/rcu 11/11] rcu: Fix typo in PER_RCU_NODE_PERIOD header comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:30 +0200
      [PATCH v2 tip/core/rcu 03/11] types: Update obsolete callback_head comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:30 +0200
      [PATCH v2 tip/core/rcu 06/11] hlist_add_tail_rcu disable sparse warning "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:30 +0200
      [PATCH v2 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
        Re: [PATCH v2 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help  text more explicit about skew_tick Josh Triplett <josh@joshtriplett.org> - 2017-04-18 02:20 +0200
          Re: [PATCH v2 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help  text more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 20:50 +0200
      [PATCH v2 tip/core/rcu 05/11] rcu: Remove obsolete comment from rcu_future_gp_cleanup() header "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
      [PATCH v2 tip/core/rcu 08/11] torture: Use correct path for Kconfig fragment for duplicates "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
      [PATCH v2 tip/core/rcu 09/11] rcu: Use bool value directly "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
      [PATCH v2 tip/core/rcu 10/11] rcu: Use true/false in assignment to bool "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
      [PATCH v2 tip/core/rcu 01/11] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
        Re: [PATCH v2 tip/core/rcu 01/11] mm: Rename SLAB_DESTROY_BY_RCU to  SLAB_TYPESAFE_BY_RCU David Rientjes <rientjes@google.com> - 2017-04-18 02:20 +0200
      [PATCH v2 tip/core/rcu 02/11] lockdep: Use "WARNING" tag on lockdep splats "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
        Re: [PATCH v2 tip/core/rcu 02/11] lockdep: Use "WARNING" tag on  lockdep splats Josh Triplett <josh@joshtriplett.org> - 2017-04-19 17:10 +0200
          Re: [PATCH v2 tip/core/rcu 02/11] lockdep: Use "WARNING" tag on  lockdep splats "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:30 +0200
      [PATCH v2 tip/core/rcu 07/11] rcu: Improve comments for hotplug/suspend/hibernate functions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-18 01:40 +0200
      Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 13:30 +0200
        Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 13:40 +0200
        Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Christian Borntraeger <borntraeger@de.ibm.com> - 2017-04-19 13:50 +0200
          Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 14:10 +0200
            Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Marc Zyngier <marc.zyngier@arm.com> - 2017-04-19 15:00 +0200
            Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 16:50 +0200
              Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Josh Triplett <josh@joshtriplett.org> - 2017-04-19 17:00 +0200
                Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 17:10 +0200
                  Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 17:20 +0200
              Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 17:00 +0200
                Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 17:20 +0200
          Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 15:30 +0200
            Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Christian Borntraeger <borntraeger@de.ibm.com> - 2017-04-19 15:30 +0200
        Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 15:10 +0200
          Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 15:20 +0200
            Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 17:40 +0200
              Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 Peter Zijlstra <peterz@infradead.org> - 2017-04-19 17:50 +0200
                Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:20 +0200
      Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 06/11] hlist_add_tail_rcu disable sparse warning "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 11/11] rcu: Fix typo in PER_RCU_NODE_PERIOD header comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 05/11] rcu: Remove obsolete comment from rcu_future_gp_cleanup() header "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 08/11] torture: Use correct path for Kconfig fragment for duplicates "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 03/11] types: Update obsolete callback_head comment "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 10/11] rcu: Use true/false in assignment to bool "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 07/11] rcu: Improve comments for hotplug/suspend/hibernate functions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 18:50 +0200
        [PATCH v3 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 19:00 +0200
        [PATCH v3 tip/core/rcu 01/11] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-04-19 19:00 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#1626050 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-19 14:10 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txWAN-3iG-17@gated-at.bofh.it>
In reply to#1626042
On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
> On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
> > 
> > So the thing Maz complained about is because KVM assumes
> > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > This series 'breaks' that.
> 
> Why is such a behaviour change not mentioned in the cover letter?
> I could not find anything in the patch descriptions that would
> indicate a slowdown. How much slower did it get?
> 
> But indeed, there are several places at KVM startup which have been
> reworked to srcu since normal rcu was too slow for several usecases.
> (Mostly registering devices and related data structures at startup,
> basically the qemu/kvm coldplug interaction)

I suspect Paul is not considering this a 'normal' RCU feature, and
therefore didn't think about changing this.

I know I was fairly surprised by this requirement when I ran into it;
and only accidentally remembered it now that maz complained.

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

#1626079 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromMarc Zyngier <marc.zyngier@arm.com>
Date2017-04-19 15:00 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txXnc-3yQ-35@gated-at.bofh.it>
In reply to#1626050
On 19/04/17 13:08, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
>> On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
>>>
>>> So the thing Maz complained about is because KVM assumes
>>> synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
>>> This series 'breaks' that.
>>
>> Why is such a behaviour change not mentioned in the cover letter?
>> I could not find anything in the patch descriptions that would
>> indicate a slowdown. How much slower did it get?
>>
>> But indeed, there are several places at KVM startup which have been
>> reworked to srcu since normal rcu was too slow for several usecases.
>> (Mostly registering devices and related data structures at startup,
>> basically the qemu/kvm coldplug interaction)
> 
> I suspect Paul is not considering this a 'normal' RCU feature, and
> therefore didn't think about changing this.
> 
> I know I was fairly surprised by this requirement when I ran into it;
> and only accidentally remembered it now that maz complained.

The issue I noticed yesterday has been addressed here:

https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev.2017.04.17a&id=6eec94fe40e294b04d32c8ef552e28fa6159bdad

and was triggered by the constant mapping/unmapping of memslots that
QEMU triggers when emulating a NOR flash that UEFI uses for storing its
variables.

So far, I'm not seeing any other spectacular regression introduced by
this series.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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

#1626193 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 16:50 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZ5E-4CC-13@gated-at.bofh.it>
In reply to#1626050
On Wed, Apr 19, 2017 at 02:08:47PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
> > On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
> > > 
> > > So the thing Maz complained about is because KVM assumes
> > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > This series 'breaks' that.
> > 
> > Why is such a behaviour change not mentioned in the cover letter?
> > I could not find anything in the patch descriptions that would
> > indicate a slowdown. How much slower did it get?
> > 
> > But indeed, there are several places at KVM startup which have been
> > reworked to srcu since normal rcu was too slow for several usecases.
> > (Mostly registering devices and related data structures at startup,
> > basically the qemu/kvm coldplug interaction)
> 
> I suspect Paul is not considering this a 'normal' RCU feature, and
> therefore didn't think about changing this.
> 
> I know I was fairly surprised by this requirement when I ran into it;
> and only accidentally remembered it now that maz complained.

Indeed -- the natural thing to have done back when KVM's scalability was
first being worked on would have been to simply change synchronize_rcu()
to synchronize_rcu_expedited().  However, at that time, these things
did try_stop_cpus() and the like, which was really bad for latency.
Moving to SRCU avoided this problem.  Of course, now that KVM uses
SRCU, why change unless there is a problem?  Besides, I vaguely recall
some KVM cases where srcu_read_lock() is used from CPUs that look to
be idle or offline from RCU's perspective, and that sort of thing only
works for SRCU.

Which reminds me...

The RCU expedited primitives have been completely rewritten since then,
and no longer use try_stop_cpus(), no longer disturb idle CPUs, and no
longer disturb nohz_full CPUs running in userspace.  In addition, there
is the rcupdate.rcu_normal kernel boot paramter for those who want to
completely avoid RCU expedited primitives.

So it seems to me to be time for the patch below.  Thoughts?

							Thanx, Paul

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

commit 333d383fad42b4bdef3d27d91e940a6eafed3f91
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed Apr 19 07:37:45 2017 -0700

    checkpatch: Remove checks for expedited grace periods
    
    There was a time when the expedited grace-period primitives
    (synchronize_rcu_expedited(), synchronize_rcu_bh_expedited(), and
    synchronize_sched_expedited()) used rather antisocial kernel
    facilities like try_stop_cpus().  However, they have since been
    housebroken to use only single-CPU IPIs, and typically cause less
    disturbance than a scheduling-clock interrupt.  Furthermore, this
    disturbance can be eliminated entirely using NO_HZ_FULL on the
    one hand or the rcupdate.rcu_normal boot parameter on the other.
    
    This commit therefore removes checkpatch's complaints about use
    of the expedited RCU primitives.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index baa3c7be04ad..64bf2a091368 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5511,23 +5511,6 @@ sub process {
 			}
 		}
 
-# Check for expedited grace periods that interrupt non-idle non-nohz
-# online CPUs.  These expedited can therefore degrade real-time response
-# if used carelessly, and should be avoided where not absolutely
-# needed.  It is always OK to use synchronize_rcu_expedited() and
-# synchronize_sched_expedited() at boot time (before real-time applications
-# start) and in error situations where real-time response is compromised in
-# any case.  Note that synchronize_srcu_expedited() does -not- interrupt
-# other CPUs, so don't warn on uses of synchronize_srcu_expedited().
-# Of course, nothing comes for free, and srcu_read_lock() and
-# srcu_read_unlock() do contain full memory barriers in payment for
-# synchronize_srcu_expedited() non-interruption properties.
-		if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {
-			WARN("EXPEDITED_RCU_GRACE_PERIOD",
-			     "expedited RCU grace periods should be avoided where they can degrade real-time response\n" . $herecurr);
-
-		}
-
 # check of hardware specific defines
 		if ($line =~ m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ m@include/asm-@) {
 			CHK("ARCH_DEFINES",

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

#1626278 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromJosh Triplett <josh@joshtriplett.org>
Date2017-04-19 17:00 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZfn-4Gn-93@gated-at.bofh.it>
In reply to#1626193
On Wed, Apr 19, 2017 at 07:47:30AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 19, 2017 at 02:08:47PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
> > > On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
> > > > 
> > > > So the thing Maz complained about is because KVM assumes
> > > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > > This series 'breaks' that.
> > > 
> > > Why is such a behaviour change not mentioned in the cover letter?
> > > I could not find anything in the patch descriptions that would
> > > indicate a slowdown. How much slower did it get?
> > > 
> > > But indeed, there are several places at KVM startup which have been
> > > reworked to srcu since normal rcu was too slow for several usecases.
> > > (Mostly registering devices and related data structures at startup,
> > > basically the qemu/kvm coldplug interaction)
> > 
> > I suspect Paul is not considering this a 'normal' RCU feature, and
> > therefore didn't think about changing this.
> > 
> > I know I was fairly surprised by this requirement when I ran into it;
> > and only accidentally remembered it now that maz complained.
> 
> Indeed -- the natural thing to have done back when KVM's scalability was
> first being worked on would have been to simply change synchronize_rcu()
> to synchronize_rcu_expedited().  However, at that time, these things
> did try_stop_cpus() and the like, which was really bad for latency.
> Moving to SRCU avoided this problem.  Of course, now that KVM uses
> SRCU, why change unless there is a problem?  Besides, I vaguely recall
> some KVM cases where srcu_read_lock() is used from CPUs that look to
> be idle or offline from RCU's perspective, and that sort of thing only
> works for SRCU.
> 
> Which reminds me...
> 
> The RCU expedited primitives have been completely rewritten since then,
> and no longer use try_stop_cpus(), no longer disturb idle CPUs, and no
> longer disturb nohz_full CPUs running in userspace.  In addition, there
> is the rcupdate.rcu_normal kernel boot paramter for those who want to
> completely avoid RCU expedited primitives.
> 
> So it seems to me to be time for the patch below.  Thoughts?
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 333d383fad42b4bdef3d27d91e940a6eafed3f91
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Wed Apr 19 07:37:45 2017 -0700
> 
>     checkpatch: Remove checks for expedited grace periods
>     
>     There was a time when the expedited grace-period primitives
>     (synchronize_rcu_expedited(), synchronize_rcu_bh_expedited(), and
>     synchronize_sched_expedited()) used rather antisocial kernel
>     facilities like try_stop_cpus().  However, they have since been
>     housebroken to use only single-CPU IPIs, and typically cause less
>     disturbance than a scheduling-clock interrupt.  Furthermore, this
>     disturbance can be eliminated entirely using NO_HZ_FULL on the
>     one hand or the rcupdate.rcu_normal boot parameter on the other.
>     
>     This commit therefore removes checkpatch's complaints about use
>     of the expedited RCU primitives.
>     
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

Still something to hesitate a bit before using, but not something
checkpatch should warn about.

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

#1626309 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-19 17:10 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZp3-4Zt-93@gated-at.bofh.it>
In reply to#1626278
On Wed, Apr 19, 2017 at 07:58:44AM -0700, Josh Triplett wrote:
> 
> Still something to hesitate a bit before using, but not something
> checkpatch should warn about.

How else will you get people to hesitate?

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

#1626315 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 17:20 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZyF-531-3@gated-at.bofh.it>
In reply to#1626309
On Wed, Apr 19, 2017 at 05:03:09PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 07:58:44AM -0700, Josh Triplett wrote:
> > 
> > Still something to hesitate a bit before using, but not something
> > checkpatch should warn about.
> 
> How else will you get people to hesitate?

The fact that checkpatch has been warning about it for quite some time
should suffice for the near future.  Longer term, there is no more reason
to complain about synchronize_rcu_expedited() than there is to complain
about smp_call_function().

							Thanx, Paul

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

#1626279 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-19 17:00 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZfn-4Gn-99@gated-at.bofh.it>
In reply to#1626193
On Wed, Apr 19, 2017 at 07:47:30AM -0700, Paul E. McKenney wrote:
> The RCU expedited primitives have been completely rewritten since then,
> and no longer use try_stop_cpus(), no longer disturb idle CPUs, and no
> longer disturb nohz_full CPUs running in userspace.  In addition, there
> is the rcupdate.rcu_normal kernel boot paramter for those who want to
> completely avoid RCU expedited primitives.
> 
> So it seems to me to be time for the patch below.  Thoughts?

So I forgot all the details again; but if I'm not mistaken it still
prods CPUs with IPIs (just not idle/nohz_full CPUs). So its still not
ideal to sprinkle them around.

Which would still argue against using them too much.

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

#1626352 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 17:20 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZyI-531-83@gated-at.bofh.it>
In reply to#1626279
On Wed, Apr 19, 2017 at 04:52:15PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 07:47:30AM -0700, Paul E. McKenney wrote:
> > The RCU expedited primitives have been completely rewritten since then,
> > and no longer use try_stop_cpus(), no longer disturb idle CPUs, and no
> > longer disturb nohz_full CPUs running in userspace.  In addition, there
> > is the rcupdate.rcu_normal kernel boot paramter for those who want to
> > completely avoid RCU expedited primitives.
> > 
> > So it seems to me to be time for the patch below.  Thoughts?
> 
> So I forgot all the details again; but if I'm not mistaken it still
> prods CPUs with IPIs (just not idle/nohz_full CPUs). So its still not
> ideal to sprinkle them around.
> 
> Which would still argue against using them too much.

True, but we have any number of things in the kernel that do IPIs,
including simple wakeups.  Adding checkpatch warnings for all of them
seems silly, as does singling out only one of them.  Hence the patch.

							Thanx, Paul

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

#1626110 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 15:30 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txXQd-3X1-5@gated-at.bofh.it>
In reply to#1626042
On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
> On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
> > 
> > So the thing Maz complained about is because KVM assumes
> > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > This series 'breaks' that.
> 
> Why is such a behaviour change not mentioned in the cover letter?
> I could not find anything in the patch descriptions that would
> indicate a slowdown. How much slower did it get?

It was an 8x slowdown in boot time of a guest OS running UEFI, from
five seconds to forty seconds.  The fix restored the original boot time.

Why didn't I report the slowdown in my cover letter?  Because I didn't
realize that I had created such a stupid bug!  ;-)

Why didn't my testing reveal the bug?  Because in my rcutorture testing,
the buggy code runs about as fast as the original, and the fixed new code
runs about an order of magnitude faster.  This is because rcutorture's
performance statistics are mostly sensitive to throughput, while Marc's
boot-time run is mostly sensitive to latency.

> But indeed, there are several places at KVM startup which have been
> reworked to srcu since normal rcu was too slow for several usecases.
> (Mostly registering devices and related data structures at startup,
> basically the qemu/kvm coldplug interaction)

And here is the patch that restored Marc's boot speed.  It simply changes
the original (buggy) fixed delay for no delay in the expedited case and
the same fixed delay in the non-expedited case.

							Thanx, Paul

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

commit 66ae176ab33dd3afa0b944d149fe8240e65743f9
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Apr 18 10:28:31 2017 -0700

    srcu: Expedite srcu_schedule_cbs_snp() callback invocation
    
    Although Tree SRCU does reduce delays when there is at least one
    synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp()
    still waits for SRCU_INTERVAL before invoking callbacks.  Since
    synchronize_srcu_expedited() now posts a callback and waits for
    that callback to do a wakeup, this destroys the expedited nature of
    synchronize_srcu_expedited().  This destruction became apparent to
    Marc Zyngier in the guise of a guest-OS bootup slowdown from five
    seconds to no fewer than forty seconds.
    
    This commit therefore invokes callbacks immediately at the end of the
    grace period when there is at least one synchronize_srcu_expedited()
    invocation pending.  This brought Marc's guest-OS bootup times back
    into the realm of reason.
    
    Reported-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Marc Zyngier <marc.zyngier@arm.com>

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index f9c684d79faa..e11b89a363f7 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -442,7 +442,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
 	int cpu;
 
 	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
-		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
+		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
+				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
 }
 
 /*

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

#1626112 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromChristian Borntraeger <borntraeger@de.ibm.com>
Date2017-04-19 15:30 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txXQe-3X1-17@gated-at.bofh.it>
In reply to#1626110
On 04/19/2017 03:22 PM, Paul E. McKenney wrote:
> On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
>> On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
>>>
>>> So the thing Maz complained about is because KVM assumes
>>> synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
>>> This series 'breaks' that.
>>
>> Why is such a behaviour change not mentioned in the cover letter?
>> I could not find anything in the patch descriptions that would
>> indicate a slowdown. How much slower did it get?
> 
> It was an 8x slowdown in boot time of a guest OS running UEFI, from
> five seconds to forty seconds.  The fix restored the original boot time.
> 
> Why didn't I report the slowdown in my cover letter?  Because I didn't
> realize that I had created such a stupid bug!  ;-)
> 
> Why didn't my testing reveal the bug?  Because in my rcutorture testing,
> the buggy code runs about as fast as the original, and the fixed new code
> runs about an order of magnitude faster.  This is because rcutorture's
> performance statistics are mostly sensitive to throughput, while Marc's
> boot-time run is mostly sensitive to latency.
> 
>> But indeed, there are several places at KVM startup which have been
>> reworked to srcu since normal rcu was too slow for several usecases.
>> (Mostly registering devices and related data structures at startup,
>> basically the qemu/kvm coldplug interaction)
> 
> And here is the patch that restored Marc's boot speed.  It simply changes
> the original (buggy) fixed delay for no delay in the expedited case and
> the same fixed delay in the non-expedited case.
> 
> 							Thanx, Paul

Ok, so it was not a fundamental rework, it was just a bug.
Then nevermind :-)

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

#1626101 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 15:10 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txXwS-3R5-27@gated-at.bofh.it>
In reply to#1626031
On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> 
> So the thing Maz complained about is because KVM assumes
> synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> This series 'breaks' that.
> 
> I've not looked hard enough at the new SRCU to see if its possible to
> re-instate that feature.

And with the fix I gave Maz, the parallelized version is near enough
to being free as well.  It was just a stupid bug on my part: I forgot
to check for expedited when scheduling callbacks.

							Thanx, Paul

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

#1626103 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-19 15:20 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txXGx-3U9-7@gated-at.bofh.it>
In reply to#1626101
On Wed, Apr 19, 2017 at 06:02:45AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> > 
> > So the thing Maz complained about is because KVM assumes
> > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > This series 'breaks' that.
> > 
> > I've not looked hard enough at the new SRCU to see if its possible to
> > re-instate that feature.
> 
> And with the fix I gave Maz, the parallelized version is near enough
> to being free as well.  It was just a stupid bug on my part: I forgot
> to check for expedited when scheduling callbacks.

Right, although for the old SRCU it was true for !expedited as well.
Just turns out the KVM memslots crud already uses
synchronize_srcu_expedited().

<rant>without a friggin' comment; hate @expedited</rant>

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

#1626402 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 17:40 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<txZS3-59Y-41@gated-at.bofh.it>
In reply to#1626103
On Wed, Apr 19, 2017 at 03:15:53PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 06:02:45AM -0700, Paul E. McKenney wrote:
> > On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> > > 
> > > So the thing Maz complained about is because KVM assumes
> > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > This series 'breaks' that.
> > > 
> > > I've not looked hard enough at the new SRCU to see if its possible to
> > > re-instate that feature.
> > 
> > And with the fix I gave Maz, the parallelized version is near enough
> > to being free as well.  It was just a stupid bug on my part: I forgot
> > to check for expedited when scheduling callbacks.
> 
> Right, although for the old SRCU it was true for !expedited as well.

Which is all good fun until someone does a call_srcu() on each and
every munmap() syscall.  ;-)

> Just turns out the KVM memslots crud already uses
> synchronize_srcu_expedited().
> 
> <rant>without a friggin' comment; hate @expedited</rant>

And I won't even try defend the old try_stop_cpus()-based expedited
algorithm in today's context, even if it did seem to be a good idea
at the time.  That said, back at that time, the expectation was that
expedited grace periods would only be used for very rare boot-time
configuration changes, at which time who cares?  But there are a lot
more expedited use cases these days, so the implementation had to change.

But the current code is much better housebroken.  ;-)

							Thanx, Paul

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

#1626410 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-19 17:50 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<ty01H-5db-11@gated-at.bofh.it>
In reply to#1626402
On Wed, Apr 19, 2017 at 08:37:03AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 19, 2017 at 03:15:53PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 19, 2017 at 06:02:45AM -0700, Paul E. McKenney wrote:
> > > On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> > > > 
> > > > So the thing Maz complained about is because KVM assumes
> > > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > > This series 'breaks' that.
> > > > 
> > > > I've not looked hard enough at the new SRCU to see if its possible to
> > > > re-instate that feature.
> > > 
> > > And with the fix I gave Maz, the parallelized version is near enough
> > > to being free as well.  It was just a stupid bug on my part: I forgot
> > > to check for expedited when scheduling callbacks.
> > 
> > Right, although for the old SRCU it was true for !expedited as well.
> 
> Which is all good fun until someone does a call_srcu() on each and
> every munmap() syscall.  ;-)

Well, that being a different SRCU domain doesn't affect the KVM memslot
domain thingy ;-)

> But the current code is much better housebroken.  ;-)

It is. But a workload that manages to hit sync_expedited in a loop on
all CPUs is still O(n^2) work. And the more sync_expedited instances we
have, the more likely that becomes.

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

#1626454 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:20 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<ty0uL-5Cb-55@gated-at.bofh.it>
In reply to#1626410
On Wed, Apr 19, 2017 at 05:43:43PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 08:37:03AM -0700, Paul E. McKenney wrote:
> > On Wed, Apr 19, 2017 at 03:15:53PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 19, 2017 at 06:02:45AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> > > > > 
> > > > > So the thing Maz complained about is because KVM assumes
> > > > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > > > This series 'breaks' that.
> > > > > 
> > > > > I've not looked hard enough at the new SRCU to see if its possible to
> > > > > re-instate that feature.
> > > > 
> > > > And with the fix I gave Maz, the parallelized version is near enough
> > > > to being free as well.  It was just a stupid bug on my part: I forgot
> > > > to check for expedited when scheduling callbacks.
> > > 
> > > Right, although for the old SRCU it was true for !expedited as well.
> > 
> > Which is all good fun until someone does a call_srcu() on each and
> > every munmap() syscall.  ;-)
> 
> Well, that being a different SRCU domain doesn't affect the KVM memslot
> domain thingy ;-)

Other than the excessive quantities of CPU time consumed...

> > But the current code is much better housebroken.  ;-)
> 
> It is. But a workload that manages to hit sync_expedited in a loop on
> all CPUs is still O(n^2) work. And the more sync_expedited instances we
> have, the more likely that becomes.

In most cases, it shouldn't be -that- hard to loop through the CPUs and
then do a single sync_expedited at the end of the loop.

							Thanx, Paul

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

#1626512 — Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:50 +0200
SubjectRe: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Message-ID<ty0XM-5M7-9@gated-at.bofh.it>
In reply to#1624906
Hello!

This v3 series contains the following fixes:

1.	Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU.

2.	Use "WARNING" tag on RCU's lockdep splats.

3.	Update obsolete callback_head comment.

4.	Make RCU_FANOUT_LEAF help text more explicit about skew_tick.

5.	Remove obsolete comment from rcu_future_gp_cleanup() header.

6.	Disable sparse warning emitted by hlist_add_tail_rcu(), courtesy
	of Michael S. Tsirkin.

7.	Improve comments for hotplug/suspend/hibernate functions.

8.	Use correct path for Kconfig fragment for duplicate rcutorture
	test scenarios.

9.	Use bool value directly for ->beenonline comparison, courtesy
	of Nicholas Mc Guire.

10.	Use true/false in assignment to bool variable rcu_nocb_poll,
	courtesy of Nicholas Mc Guire.

11.	Fix typo in PER_RCU_NODE_PERIOD header comment.

Changes since v2:

o	Fixed indentation in RCU_FANOOUT_LEAF Kconfig option help text,
	as noted by Josh Triplett.

o	Applied feedback from David Rientjes.

Changes since v1:

o	Applied review feedback from Peter Zijlstra, Vlastimil Babka,
	and Eric Dumazet.

o	Dropped v1 patch #7 ("Add smp_mb__after_atomic() to
	sync_exp_work_done()"), as ensuing discussion confirmed that
	smp_mb__before_atomic() guarantees a full barrier.

o	Moved v1 patch #9 ("Use static initialization for "srcu" in
	mm/mmu_notifier.c") to the srcu series because 0day Test Robot
	showed that it needs to be there.

							Thanx, Paul

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

 Documentation/RCU/00-INDEX                               |    2 
 Documentation/RCU/rculist_nulls.txt                      |    6 -
 Documentation/RCU/whatisRCU.txt                          |    3 
 drivers/gpu/drm/i915/i915_gem.c                          |    2 
 drivers/gpu/drm/i915/i915_gem_request.h                  |    2 
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c          |    2 
 fs/jbd2/journal.c                                        |    2 
 fs/signalfd.c                                            |    2 
 include/linux/dma-fence.h                                |    4 
 include/linux/rculist.h                                  |    3 
 include/linux/slab.h                                     |    6 -
 include/linux/types.h                                    |    2 
 include/net/sock.h                                       |    2 
 init/Kconfig                                             |   10 +
 kernel/fork.c                                            |    4 
 kernel/locking/lockdep.c                                 |   86 +++++++--------
 kernel/locking/rtmutex-debug.c                           |    9 -
 kernel/rcu/tree.c                                        |   49 ++++++--
 kernel/rcu/tree_plugin.h                                 |    2 
 kernel/signal.c                                          |    2 
 mm/kasan/kasan.c                                         |    6 -
 mm/kmemcheck.c                                           |    2 
 mm/rmap.c                                                |    4 
 mm/slab.c                                                |    6 -
 mm/slab.h                                                |    4 
 mm/slab_common.c                                         |    6 -
 mm/slob.c                                                |    6 -
 mm/slub.c                                                |   12 +-
 net/dccp/ipv4.c                                          |    2 
 net/dccp/ipv6.c                                          |    2 
 net/ipv4/tcp_ipv4.c                                      |    2 
 net/ipv6/tcp_ipv6.c                                      |    2 
 net/llc/af_llc.c                                         |    2 
 net/llc/llc_conn.c                                       |    4 
 net/llc/llc_sap.c                                        |    2 
 net/netfilter/nf_conntrack_core.c                        |    8 -
 net/smc/af_smc.c                                         |    2 
 tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh |    2 
 38 files changed, 158 insertions(+), 116 deletions(-)

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

#1626517 — [PATCH v3 tip/core/rcu 06/11] hlist_add_tail_rcu disable sparse warning

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:50 +0200
Subject[PATCH v3 tip/core/rcu 06/11] hlist_add_tail_rcu disable sparse warning
Message-ID<ty0XN-5M7-43@gated-at.bofh.it>
In reply to#1626512
From: "Michael S. Tsirkin" <mst@redhat.com>

sparse is unhappy about this code in hlist_add_tail_rcu:

        struct hlist_node *i, *last = NULL;

        for (i = hlist_first_rcu(h); i; i = hlist_next_rcu(i))
                last = i;

This is because hlist_next_rcu and hlist_next_rcu return
__rcu pointers.

It's a false positive - it's a write side primitive and so
does not need to be called in a read side critical section.

The following trivial patch disables the warning
without changing the behaviour in any way.

Note: __hlist_for_each_rcu would also remove the warning but it would be
confusing since it calls rcu_derefence and is designed to run in the rcu
read side critical section.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 include/linux/rculist.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 4f7a9561b8c4..b1fd8bf85fdc 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -509,7 +509,8 @@ static inline void hlist_add_tail_rcu(struct hlist_node *n,
 {
 	struct hlist_node *i, *last = NULL;
 
-	for (i = hlist_first_rcu(h); i; i = hlist_next_rcu(i))
+	/* Note: write side code, so rcu accessors are not needed. */
+	for (i = h->first; i; i = i->next)
 		last = i;
 
 	if (last) {
-- 
2.5.2

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

#1626519 — [PATCH v3 tip/core/rcu 11/11] rcu: Fix typo in PER_RCU_NODE_PERIOD header comment

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:50 +0200
Subject[PATCH v3 tip/core/rcu 11/11] rcu: Fix typo in PER_RCU_NODE_PERIOD header comment
Message-ID<ty0XN-5M7-45@gated-at.bofh.it>
In reply to#1626512
This commit just changes a "the the" to "the" to reduce repetition.

Reported-by: Michalis Kokologiannakis <mixaskok@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcu/tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7c238604df18..b1679e8cc5ed 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -199,7 +199,7 @@ static const int gp_cleanup_delay;
 
 /*
  * Number of grace periods between delays, normalized by the duration of
- * the delay.  The longer the the delay, the more the grace periods between
+ * the delay.  The longer the delay, the more the grace periods between
  * each delay.  The reason for this normalization is that it means that,
  * for non-zero delays, the overall slowdown of grace periods is constant
  * regardless of the duration of the delay.  This arrangement balances
-- 
2.5.2

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

#1626520 — [PATCH v3 tip/core/rcu 05/11] rcu: Remove obsolete comment from rcu_future_gp_cleanup() header

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:50 +0200
Subject[PATCH v3 tip/core/rcu 05/11] rcu: Remove obsolete comment from rcu_future_gp_cleanup() header
Message-ID<ty0XN-5M7-47@gated-at.bofh.it>
In reply to#1626512
The rcu_nocb_gp_cleanup() function is now invoked elsewhere, so this
commit drags this comment into the year 2017.

Reported-by: Michalis Kokologiannakis <mixaskok@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcu/tree.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 50fee7689e71..bdaa69d23a8a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1793,9 +1793,7 @@ rcu_start_future_gp(struct rcu_node *rnp, struct rcu_data *rdp,
 
 /*
  * Clean up any old requests for the just-ended grace period.  Also return
- * whether any additional grace periods have been requested.  Also invoke
- * rcu_nocb_gp_cleanup() in order to wake up any no-callbacks kthreads
- * waiting for this grace period to complete.
+ * whether any additional grace periods have been requested.
  */
 static int rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp)
 {
-- 
2.5.2

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

#1626521 — [PATCH v3 tip/core/rcu 08/11] torture: Use correct path for Kconfig fragment for duplicates

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-04-19 18:50 +0200
Subject[PATCH v3 tip/core/rcu 08/11] torture: Use correct path for Kconfig fragment for duplicates
Message-ID<ty0XN-5M7-53@gated-at.bofh.it>
In reply to#1626512
Currently, the rcutorture scripting will give an error message if
running a duplicate scenario that happens also to have a non-existent
build directory (b1, b2, ... in the rcutorture directory).  Worse yet, if
the build directory has already been created and used for a real build,
the script will silently grab the wrong Kconfig fragment, which could
cause confusion to the poor sap (me) analyzing old test results.  At
least the actual test runs correctly...

This commit therefore accesses the Kconfig fragment from the results
directory corresponding to the first of the duplicate scenarios, for
which a build was actually carried out.  This prevents both the messages
and at least one form of later confusion.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index ea6e373edc27..93eede4e8fbe 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -170,7 +170,7 @@ qemu_append="`identify_qemu_append "$QEMU"`"
 # Pull in Kconfig-fragment boot parameters
 boot_args="`configfrag_boot_params "$boot_args" "$config_template"`"
 # Generate kernel-version-specific boot parameters
-boot_args="`per_version_boot_params "$boot_args" $builddir/.config $seconds`"
+boot_args="`per_version_boot_params "$boot_args" $resdir/.config $seconds`"
 
 if test -n "$TORTURE_BUILDONLY"
 then
-- 
2.5.2

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.kernel

csiph-web