Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
On Wed, Dec 16, 2020 at 08:59:30AM -0800, Paul E. McKenney wrote: > On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > > > > Frederic Weisbecker (19): > > rcu/nocb: Turn enabled/offload states into a common flag > > rcu/nocb: Provide basic callback offloading state machine bits > > rcu/nocb: Always init segcblist on CPU up > > rcu/nocb: De-offloading CB kthread > > rcu/nocb: Don't deoffload an offline CPU with pending work > > rcu/nocb: De-offloading GP kthread > > rcu/nocb: Re-offload support > > rcu/nocb: Shutdown nocb timer on de-offloading > > rcu: Flush bypass before setting SEGCBLIST_SOFTIRQ_ONLY > > rcu/nocb: Set SEGCBLIST_SOFTIRQ_ONLY at the very last stage of > > de-offloading > > rcu/nocb: Only cond_resched() from actual offloaded batch processing > > rcu/nocb: Process batch locally as long as offloading isn't complete > > rcu/nocb: Locally accelerate callbacks as long as offloading isn't > > complete > > tools/rcutorture: Support nocb toggle in TREE01 > > I applied the above, with the usual commit-log wordsmithing. > > > rcutorture: Remove weak nocb declarations > > rcutorture: Export nocb (de)offloading functions > > These I folded into the rcutorture commit, as you suggested. Good! > > > cpu/hotplug: Add lockdep_is_cpus_held() > > timer: Add timer_curr_running() > > I applied these two. > > > rcu/nocb: Detect unsafe checks for offloaded rdp > > This one didn't apply, probably due to recent changes in -rcu. Could > you please take a look? Ok I'm going to rebase it. > I believe that the following enhancements will be needed: > > o Forbid toggling of offlined CPUs. This is a simple rule that > results in deterministic success or failure. The current setup > (which I freely admit that I suggested) will fail very rarely, > only if a newly offlined offloaded CPU is toggled before its > remaining callbacks are invoked. The current state is therefore > an accident waiting to happen. > > This will entail fixing a few comments as well. Sure, I'm always glad to remove lines! > > o Drain the bypass early in the de-offloading process and prohibit > queuing onto the bypass anywhere in the toggling process. > Then the only CPUs permitted to use the bypass are those that > are fully offloaded. This approach allows rcu_core() and the > rcuog kthreads to safely manipulate callbacks and grace periods > concurrently. (Famous last words!) This might address the > rcutorture writer stall warnings I am seeing. > > This will entail fixing a few comments as well. Ok, I'm checking that. > > o Avoid double write to rdp->nocb_cb_sleep in nocb_cb_wait(). > Unless there is some reason why this is absolutely required. > It will cause confusion as it is. Ok. > > o What bad thing happens if we de-offload the CPU corresponding to > the nocb GP kthread? It does work fine when that CPU is offlined. > > Coincidence or not, all but one of the rcutorture writer stalls > is followed by a message refusing to de-offload this CPU. It probably started with a brainfart that I elaborated a bit too far. Let me check that again. > > o The nocb_gp_update_state() function's return value seems backwards. > What am I missing here? Indeed I should rename it to nocb_gp_check_rdp() or something. > > o __rcu_nocb_rdp_deoffload(): Why move rcu_nocb_lock_irqsave() > across a comment? Because the comment only concerns the locking? > > o We need better debug. For example, "Can't deoffload an rdp GP > leader (yet)". Well, which CPU? For another example, we need > deoffload state in rcutorture writer-stall dumps. Ok. > > I intend to do the following, and, if feasible, fold them into the > original commits: > > o Make rcu_segcblist_is_offloaded() use "&&" instead of a > nested "if" statement. > > o nocb_cb_wait() needs the "^^^ Ensure CB invocation follows > _sleep test" to be adjusted so that it is properly attached to > its smp_load_acquire(). > > o nocb_cb_wait() -- alphabetical order for local variables, please! > Yeah, I know, others like inverted tree for reasons that escape me > completely. Ah, ok noted. Thanks! > Thanx, Paul > > > include/linux/cpu.h| 1 + > > include/linux/rcu_segcblist.h | 119 +- > > include/linux/rcupdate.h | 4 + > > include/linux/timer.h | 2 + > > kernel/cpu.c | 7 + > > kernel/rcu/rcu_segcblist.c | 13 +- > > kernel/rcu/rcu_segcblist.h | 45 ++- > > kernel/rcu/rcutorture.c
Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > This keeps growing up. Rest assured, most of it is debug code and sanity > checks. > > Boqun Feng found that holding rnp lock while updating the offloaded > state of an rdp isn't needed, and he was right despite my initial > reaction. The sites that read the offloaded state while holding the rnp > lock are actually protected because they read it locally in a non > preemptible context. > > So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to > make sure I'm not missing something, I added sanity checks that ensure > we always read the offloaded state in a safe way (3 last patches). > > Still passes TREE01 (but I had to fight!) > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > rcu/nocb-toggle-v4 > > HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe > > Thanks, > Frederic Thank you both! > --- > > Frederic Weisbecker (19): > rcu/nocb: Turn enabled/offload states into a common flag > rcu/nocb: Provide basic callback offloading state machine bits > rcu/nocb: Always init segcblist on CPU up > rcu/nocb: De-offloading CB kthread > rcu/nocb: Don't deoffload an offline CPU with pending work > rcu/nocb: De-offloading GP kthread > rcu/nocb: Re-offload support > rcu/nocb: Shutdown nocb timer on de-offloading > rcu: Flush bypass before setting SEGCBLIST_SOFTIRQ_ONLY > rcu/nocb: Set SEGCBLIST_SOFTIRQ_ONLY at the very last stage of > de-offloading > rcu/nocb: Only cond_resched() from actual offloaded batch processing > rcu/nocb: Process batch locally as long as offloading isn't complete > rcu/nocb: Locally accelerate callbacks as long as offloading isn't > complete > tools/rcutorture: Support nocb toggle in TREE01 I applied the above, with the usual commit-log wordsmithing. > rcutorture: Remove weak nocb declarations > rcutorture: Export nocb (de)offloading functions These I folded into the rcutorture commit, as you suggested. > cpu/hotplug: Add lockdep_is_cpus_held() > timer: Add timer_curr_running() I applied these two. > rcu/nocb: Detect unsafe checks for offloaded rdp This one didn't apply, probably due to recent changes in -rcu. Could you please take a look? I do get the occasional rcutorture writer stall in TREE01. I sent you the console log offlist, but I suspect that this is related to some of your questions. I am retesting with the new TREE01 boot parameters removed (but with the new rcu_nocbs= layout). These stalls are temporary, with torturing progressing normally after the warnings are printed. This warning usually indicates that grace periods are progressing I believe that the following enhancements will be needed: o Forbid toggling of offlined CPUs. This is a simple rule that results in deterministic success or failure. The current setup (which I freely admit that I suggested) will fail very rarely, only if a newly offlined offloaded CPU is toggled before its remaining callbacks are invoked. The current state is therefore an accident waiting to happen. This will entail fixing a few comments as well. o Drain the bypass early in the de-offloading process and prohibit queuing onto the bypass anywhere in the toggling process. Then the only CPUs permitted to use the bypass are those that are fully offloaded. This approach allows rcu_core() and the rcuog kthreads to safely manipulate callbacks and grace periods concurrently. (Famous last words!) This might address the rcutorture writer stall warnings I am seeing. This will entail fixing a few comments as well. o Avoid double write to rdp->nocb_cb_sleep in nocb_cb_wait(). Unless there is some reason why this is absolutely required. It will cause confusion as it is. o What bad thing happens if we de-offload the CPU corresponding to the nocb GP kthread? It does work fine when that CPU is offlined. Coincidence or not, all but one of the rcutorture writer stalls is followed by a message refusing to de-offload this CPU. o The nocb_gp_update_state() function's return value seems backwards. What am I missing here? o __rcu_nocb_rdp_deoffload(): Why move rcu_nocb_lock_irqsave() across a comment? o We need better debug. For example, "Can't deoffload an rdp GP leader (yet)". Well, which CPU? For another example, we need deoffload state in rcutorture writer-stall dumps. I intend to do the following, and, if feasible, fold them into the original commits: o Make rcu_segcblist_is_offloaded() use "&&" instead of a nested "if" statement. o nocb_cb_wait() needs the "^^^ Ensure CB invocation follows _sleep test" to be adjusted so that it is properly attached
Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
On Wed, Dec 09, 2020 at 05:21:58PM -0800, Paul E. McKenney wrote: > On Tue, Dec 08, 2020 at 01:51:04PM +0100, Frederic Weisbecker wrote: > > Hi Boqun Feng, > > > > On Tue, Dec 08, 2020 at 10:41:31AM +0800, Boqun Feng wrote: > > > Hi Frederic, > > > > > > On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > > > > This keeps growing up. Rest assured, most of it is debug code and sanity > > > > checks. > > > > > > > > Boqun Feng found that holding rnp lock while updating the offloaded > > > > state of an rdp isn't needed, and he was right despite my initial > > > > reaction. The sites that read the offloaded state while holding the rnp > > > > lock are actually protected because they read it locally in a non > > > > preemptible context. > > > > > > > > So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to > > > > make sure I'm not missing something, I added sanity checks that ensure > > > > we always read the offloaded state in a safe way (3 last patches). > > > > > > > > Still passes TREE01 (but I had to fight!) > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > > rcu/nocb-toggle-v4 > > > > > > > > HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe > > > > > > > > > > This whole series look good to me, plus I've run a test, so far > > > everything seems working ;-) Here is my setup for the test: > > > > > > I'm using a ARM64 guest (running on Hyper-V) to do the test, and the > > > guest has 8 VCPUs. The code I'm using is v5.10-rc6 + Hyper-V ARM64 guest > > > support [1] + your patchset (I actually did a merge from your > > > rcu/nocb-toggle-v5 branch, because IIUC some modification for rcutorture > > > is still in Paul's tree). I compiled with my normal configuration for > > > ARM64 Hyper-V guest plus TREE01, boot the kernel with: > > > > > > ignore_loglevel rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 > > > rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7 > > > > > > and run rcutorture via: > > > > > > modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 > > > > > > I ran the rcutorture twice, one last for a week or so and one for a day > > > or two and I didn't observe any problem so far. The latest test summary > > > is: > > > > > > [...] rcu-torture: rtc: f794686f ver: 2226396 tfle: 0 rta: > > > 2226397 rtaf: 0 rtf: 2226385 rtmbe: 0 rtmbkf: 0/1390141 rtbe: 0 rtbke: 0 > > > rtbre: 0 rtbf: 0 rtb: 0 nt: 181415346 onoff: 0/0:0/0 -1,0:-1,0 0:0 > > > (HZ=1000) barrier: 0/0:0 read-exits: 108102 nocb-toggles: 306964:306974 > > > > > > Is there anything I'm missing for a useful test? Do you have other setup > > > (kernel cmdline or rcutorture parameters) that you want me to try? > > > > Thanks a lot for reviewing and testing. You seem to have tested with the > > right > > options, I have nothing better to suggest. Plus I'm glad you tested on > > ARM64. x86 is the only target I have tested so far. > > Boqun, would you be willing to give your Tested-by? > Sure, FWIW, for the whole series, feel free to add: Tested-by: Boqun Feng Regards, Boqun > Thanx, Paul
Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
On Tue, Dec 08, 2020 at 01:51:04PM +0100, Frederic Weisbecker wrote: > Hi Boqun Feng, > > On Tue, Dec 08, 2020 at 10:41:31AM +0800, Boqun Feng wrote: > > Hi Frederic, > > > > On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > > > This keeps growing up. Rest assured, most of it is debug code and sanity > > > checks. > > > > > > Boqun Feng found that holding rnp lock while updating the offloaded > > > state of an rdp isn't needed, and he was right despite my initial > > > reaction. The sites that read the offloaded state while holding the rnp > > > lock are actually protected because they read it locally in a non > > > preemptible context. > > > > > > So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to > > > make sure I'm not missing something, I added sanity checks that ensure > > > we always read the offloaded state in a safe way (3 last patches). > > > > > > Still passes TREE01 (but I had to fight!) > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > rcu/nocb-toggle-v4 > > > > > > HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe > > > > > > > This whole series look good to me, plus I've run a test, so far > > everything seems working ;-) Here is my setup for the test: > > > > I'm using a ARM64 guest (running on Hyper-V) to do the test, and the > > guest has 8 VCPUs. The code I'm using is v5.10-rc6 + Hyper-V ARM64 guest > > support [1] + your patchset (I actually did a merge from your > > rcu/nocb-toggle-v5 branch, because IIUC some modification for rcutorture > > is still in Paul's tree). I compiled with my normal configuration for > > ARM64 Hyper-V guest plus TREE01, boot the kernel with: > > > > ignore_loglevel rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 > > rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7 > > > > and run rcutorture via: > > > > modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 > > > > I ran the rcutorture twice, one last for a week or so and one for a day > > or two and I didn't observe any problem so far. The latest test summary > > is: > > > > [...] rcu-torture: rtc: f794686f ver: 2226396 tfle: 0 rta: > > 2226397 rtaf: 0 rtf: 2226385 rtmbe: 0 rtmbkf: 0/1390141 rtbe: 0 rtbke: 0 > > rtbre: 0 rtbf: 0 rtb: 0 nt: 181415346 onoff: 0/0:0/0 -1,0:-1,0 0:0 > > (HZ=1000) barrier: 0/0:0 read-exits: 108102 nocb-toggles: 306964:306974 > > > > Is there anything I'm missing for a useful test? Do you have other setup > > (kernel cmdline or rcutorture parameters) that you want me to try? > > Thanks a lot for reviewing and testing. You seem to have tested with the right > options, I have nothing better to suggest. Plus I'm glad you tested on > ARM64. x86 is the only target I have tested so far. Boqun, would you be willing to give your Tested-by? Thanx, Paul
Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
Hi Boqun Feng, On Tue, Dec 08, 2020 at 10:41:31AM +0800, Boqun Feng wrote: > Hi Frederic, > > On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > > This keeps growing up. Rest assured, most of it is debug code and sanity > > checks. > > > > Boqun Feng found that holding rnp lock while updating the offloaded > > state of an rdp isn't needed, and he was right despite my initial > > reaction. The sites that read the offloaded state while holding the rnp > > lock are actually protected because they read it locally in a non > > preemptible context. > > > > So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to > > make sure I'm not missing something, I added sanity checks that ensure > > we always read the offloaded state in a safe way (3 last patches). > > > > Still passes TREE01 (but I had to fight!) > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > rcu/nocb-toggle-v4 > > > > HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe > > > > This whole series look good to me, plus I've run a test, so far > everything seems working ;-) Here is my setup for the test: > > I'm using a ARM64 guest (running on Hyper-V) to do the test, and the > guest has 8 VCPUs. The code I'm using is v5.10-rc6 + Hyper-V ARM64 guest > support [1] + your patchset (I actually did a merge from your > rcu/nocb-toggle-v5 branch, because IIUC some modification for rcutorture > is still in Paul's tree). I compiled with my normal configuration for > ARM64 Hyper-V guest plus TREE01, boot the kernel with: > > ignore_loglevel rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 > rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7 > > and run rcutorture via: > > modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 > > I ran the rcutorture twice, one last for a week or so and one for a day > or two and I didn't observe any problem so far. The latest test summary > is: > > [...] rcu-torture: rtc: f794686f ver: 2226396 tfle: 0 rta: > 2226397 rtaf: 0 rtf: 2226385 rtmbe: 0 rtmbkf: 0/1390141 rtbe: 0 rtbke: 0 > rtbre: 0 rtbf: 0 rtb: 0 nt: 181415346 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=1000) > barrier: 0/0:0 read-exits: 108102 nocb-toggles: 306964:306974 > > Is there anything I'm missing for a useful test? Do you have other setup > (kernel cmdline or rcutorture parameters) that you want me to try? Thanks a lot for reviewing and testing. You seem to have tested with the right options, I have nothing better to suggest. Plus I'm glad you tested on ARM64. x86 is the only target I have tested so far.
Re: [PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
Hi Frederic, On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote: > This keeps growing up. Rest assured, most of it is debug code and sanity > checks. > > Boqun Feng found that holding rnp lock while updating the offloaded > state of an rdp isn't needed, and he was right despite my initial > reaction. The sites that read the offloaded state while holding the rnp > lock are actually protected because they read it locally in a non > preemptible context. > > So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to > make sure I'm not missing something, I added sanity checks that ensure > we always read the offloaded state in a safe way (3 last patches). > > Still passes TREE01 (but I had to fight!) > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > rcu/nocb-toggle-v4 > > HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe > This whole series look good to me, plus I've run a test, so far everything seems working ;-) Here is my setup for the test: I'm using a ARM64 guest (running on Hyper-V) to do the test, and the guest has 8 VCPUs. The code I'm using is v5.10-rc6 + Hyper-V ARM64 guest support [1] + your patchset (I actually did a merge from your rcu/nocb-toggle-v5 branch, because IIUC some modification for rcutorture is still in Paul's tree). I compiled with my normal configuration for ARM64 Hyper-V guest plus TREE01, boot the kernel with: ignore_loglevel rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7 and run rcutorture via: modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 I ran the rcutorture twice, one last for a week or so and one for a day or two and I didn't observe any problem so far. The latest test summary is: [...] rcu-torture: rtc: f794686f ver: 2226396 tfle: 0 rta: 2226397 rtaf: 0 rtf: 2226385 rtmbe: 0 rtmbkf: 0/1390141 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 181415346 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=1000) barrier: 0/0:0 read-exits: 108102 nocb-toggles: 306964:306974 Is there anything I'm missing for a useful test? Do you have other setup (kernel cmdline or rcutorture parameters) that you want me to try? Regards, Boqun > Thanks, > Frederic > --- > > Frederic Weisbecker (19): > rcu/nocb: Turn enabled/offload states into a common flag > rcu/nocb: Provide basic callback offloading state machine bits > rcu/nocb: Always init segcblist on CPU up > rcu/nocb: De-offloading CB kthread > rcu/nocb: Don't deoffload an offline CPU with pending work > rcu/nocb: De-offloading GP kthread > rcu/nocb: Re-offload support > rcu/nocb: Shutdown nocb timer on de-offloading > rcu: Flush bypass before setting SEGCBLIST_SOFTIRQ_ONLY > rcu/nocb: Set SEGCBLIST_SOFTIRQ_ONLY at the very last stage of > de-offloading > rcu/nocb: Only cond_resched() from actual offloaded batch processing > rcu/nocb: Process batch locally as long as offloading isn't complete > rcu/nocb: Locally accelerate callbacks as long as offloading isn't > complete > tools/rcutorture: Support nocb toggle in TREE01 > rcutorture: Remove weak nocb declarations > rcutorture: Export nocb (de)offloading functions > cpu/hotplug: Add lockdep_is_cpus_held() > timer: Add timer_curr_running() > rcu/nocb: Detect unsafe checks for offloaded rdp > > > include/linux/cpu.h| 1 + > include/linux/rcu_segcblist.h | 119 +- > include/linux/rcupdate.h | 4 + > include/linux/timer.h | 2 + > kernel/cpu.c | 7 + > kernel/rcu/rcu_segcblist.c | 13 +- > kernel/rcu/rcu_segcblist.h | 45 ++- > kernel/rcu/rcutorture.c| 3 - > kernel/rcu/tree.c | 49 ++- > kernel/rcu/tree.h | 2 + > kernel/rcu/tree_plugin.h | 416 > +++-- > kernel/time/timer.c| 13 + > .../selftests/rcutorture/configs/rcu/TREE01.boot | 4 +- > 13 files changed, 614 insertions(+), 64 deletions(-)
[PATCH 00/19] rcu/nocb: De-offload and re-offload support v4
This keeps growing up. Rest assured, most of it is debug code and sanity checks. Boqun Feng found that holding rnp lock while updating the offloaded state of an rdp isn't needed, and he was right despite my initial reaction. The sites that read the offloaded state while holding the rnp lock are actually protected because they read it locally in a non preemptible context. So I removed the rnp lock in "rcu/nocb: De-offloading CB". And just to make sure I'm not missing something, I added sanity checks that ensure we always read the offloaded state in a safe way (3 last patches). Still passes TREE01 (but I had to fight!) git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git rcu/nocb-toggle-v4 HEAD: 579e15efa48fb6fc4ecf14961804051f385807fe Thanks, Frederic --- Frederic Weisbecker (19): rcu/nocb: Turn enabled/offload states into a common flag rcu/nocb: Provide basic callback offloading state machine bits rcu/nocb: Always init segcblist on CPU up rcu/nocb: De-offloading CB kthread rcu/nocb: Don't deoffload an offline CPU with pending work rcu/nocb: De-offloading GP kthread rcu/nocb: Re-offload support rcu/nocb: Shutdown nocb timer on de-offloading rcu: Flush bypass before setting SEGCBLIST_SOFTIRQ_ONLY rcu/nocb: Set SEGCBLIST_SOFTIRQ_ONLY at the very last stage of de-offloading rcu/nocb: Only cond_resched() from actual offloaded batch processing rcu/nocb: Process batch locally as long as offloading isn't complete rcu/nocb: Locally accelerate callbacks as long as offloading isn't complete tools/rcutorture: Support nocb toggle in TREE01 rcutorture: Remove weak nocb declarations rcutorture: Export nocb (de)offloading functions cpu/hotplug: Add lockdep_is_cpus_held() timer: Add timer_curr_running() rcu/nocb: Detect unsafe checks for offloaded rdp include/linux/cpu.h| 1 + include/linux/rcu_segcblist.h | 119 +- include/linux/rcupdate.h | 4 + include/linux/timer.h | 2 + kernel/cpu.c | 7 + kernel/rcu/rcu_segcblist.c | 13 +- kernel/rcu/rcu_segcblist.h | 45 ++- kernel/rcu/rcutorture.c| 3 - kernel/rcu/tree.c | 49 ++- kernel/rcu/tree.h | 2 + kernel/rcu/tree_plugin.h | 416 +++-- kernel/time/timer.c| 13 + .../selftests/rcutorture/configs/rcu/TREE01.boot | 4 +- 13 files changed, 614 insertions(+), 64 deletions(-)
