by Lai Jiangshan

[permalink] [raw]

Subject: Re: [PATCH V2 09/11] rcu: Implement PCPU_RCU_PREEMPT_COUNT framework

On Wed, Apr 24, 2024 at 2:19 AM Joel Fernandes <[email protected]> wrote:
>
> On Sun, Apr 7, 2024 at 5:04 AM Lai Jiangshan <[email protected]> wrote:
> >
> > From: Lai Jiangshan <[email protected]>
> >
> > When the arch code provides HAVE_PCPU_RCU_PREEMPT_COUNT and the
> > corresponding functions, rcu core uses the functions to implement
> > rcu_preempt_depth(), special bits, switching and so on.
> >
> > Cc: "Paul E. McKenney" <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Frederic Weisbecker <[email protected]>
> > Signed-off-by: Lai Jiangshan <[email protected]>
> > ---
> > include/linux/rcupdate.h | 33 +++++++++++++++++++++++++++++++++
> > kernel/rcu/Kconfig | 8 ++++++++
> > kernel/rcu/rcu.h | 4 ++++
> > kernel/rcu/tree_plugin.h | 8 ++++++++
> > 4 files changed, 53 insertions(+)
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 328667ae8086..e3e5ce44c7dc 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -70,6 +70,8 @@ static inline bool same_state_synchronize_rcu(unsigned long oldstate1, unsigned
> >
> > void rcu_read_unlock_special(void);
> >
> > +#ifndef CONFIG_PCPU_RCU_PREEMPT_COUNT
> > +
> > void __rcu_read_lock(void);
> > void __rcu_read_unlock(void);
> >
> > @@ -81,6 +83,37 @@ void __rcu_read_unlock(void);
> > */
> > #define rcu_preempt_depth() READ_ONCE(current->rcu_read_lock_nesting)
> > #define rcu_preempt_depth_set(val) WRITE_ONCE(current->rcu_read_lock_nesting, (val))
> > +#define pcpu_rcu_preempt_special_set() do { } while (0)
> > +#define pcpu_rcu_preempt_special_clear() do { } while (0)
> > +
> > +#else /* #ifndef CONFIG_PCPU_RCU_PREEMPT_COUNT */
> > +
> > +#include <asm/rcu_preempt.h>
> > +
> > +static __always_inline void __rcu_read_lock(void)
> > +{
> > + pcpu_rcu_preempt_count_add(1);
> > + barrier();
> > +}
> > +
> > +static __always_inline void __rcu_read_unlock(void)
> > +{
> > + barrier();
> > + if (unlikely(pcpu_rcu_preempt_count_dec_and_test()))
> > + pcpu_rcu_read_unlock_special();
> > +}
>
> Previous code had comments about the barrier(); , can you add back
> those comments?
>
> Also there was a compiler barrier in the body of the if() as well?
>

The two "if"s in the referenced __rcu_read_unlock() are condensed into
a single "if" ("if (unlikely(pcpu_rcu_preempt_count_dec_and_test()))"),
so there is no extra barrier() needed in the body of the "if" which
is analogue to the body of the second "if" of the referenced
__rcu_read_unlock().

The special bit and the rcu_depth_count are condensed, so the code
mostly follows the way how preempt_enable() works.

Thanks
Lai

> For reference:
>
> void __rcu_read_unlock(void)
> {
> struct task_struct *t = current;
>
> barrier(); // critical section before exit code.
> if (rcu_preempt_read_exit() == 0) {
> barrier(); // critical-section exit before .s check.
> if (unlikely(READ_ONCE(t->rcu_read_unlock_special.s)))
> rcu_read_unlock_special(t);
> }

2024-05-20 20:03:25

by Paul E. McKenney

[permalink] [raw]

Subject: Re: [PATCH V2 00/11] rcu/x86: Use per-cpu rcu preempt count

On Sun, Apr 07, 2024 at 05:05:47PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <[email protected]>
>
>
> Changed from v1:
> Merge thunk_64.S and thunk_32.S into thunk.S
> Add missing #ifdef in arch/x86/kernel/cpu/common.c
>
> X86 can access percpu data in a single instruction.
>
> Use per-cpu rcu preempt count and make it able to be inlined.
>
> patch 1-8: prepare
> patch 9-11: implement PCPU_RCU_PREEMPT_COUNT
>
> Cc: "Paul E. McKenney" <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Frederic Weisbecker <[email protected]>

Hello, Lai!

This is really cool stuff, thank you!!!

Two big questions remain: (1) What system-level net performance benefit
is there, taking the increased context-switch overhead into account and
(2) Are the scheduler maintainers on board with these changes?

On #1, I do well recall your ca. 2019 points about the improved code
generated, but I have seen cases where improved code actually ran
more slowly. My guess is that you have the best chance of seeing
system-level benefits on low-end x86 platforms, perhaps the old Atom
or Celeron systems. The rcuref module provides a good way of doing
microbenchmarks, which would be a good start. Other metrics that
might help include overall kernel code size.

On #2, good data for #1 would help greatly.

Thoughts?

Thanx, Paul

> Lai Jiangshan (11):
> lib: Use rcu_preempt_depth() to replace current->rcu_read_lock_nesting
> rcu: Move rcu_preempt_depth_set() to rcupdate.h
> rcu: Reorder tree_exp.h after tree_plugin.h
> rcu: Add macros set_rcu_preempt_special() and
> clear_rcu_preempt_special()
> rcu: Make rcu_read_unlock_special() global
> rcu: Rename marco __LINUX_RCU_H to __KERNEL_RCU_H
> sched/core: Add rcu_preempt_switch()
> x86/entry: Merge thunk_64.S and thunk_32.S into thunk.S
> rcu: Implement PCPU_RCU_PREEMPT_COUNT framework
> x86/rcu: Add rcu_preempt_count
> x86/rcu: Add THUNK rcu_read_unlock_special_thunk
>
> arch/x86/Kconfig | 1 +
> arch/x86/entry/Makefile | 2 +-
> arch/x86/entry/{thunk_64.S => thunk.S} | 5 ++
> arch/x86/entry/thunk_32.S | 18 ----
> arch/x86/include/asm/current.h | 3 +
> arch/x86/include/asm/rcu_preempt.h | 109 +++++++++++++++++++++++++
> arch/x86/kernel/cpu/common.c | 4 +
> include/linux/rcupdate.h | 36 ++++++++
> kernel/rcu/Kconfig | 8 ++
> kernel/rcu/rcu.h | 15 +++-
> kernel/rcu/tree.c | 2 +-
> kernel/rcu/tree_exp.h | 2 +-
> kernel/rcu/tree_plugin.h | 41 ++++++----
> kernel/sched/core.c | 2 +
> lib/locking-selftest.c | 6 +-
> 15 files changed, 212 insertions(+), 42 deletions(-)
> rename arch/x86/entry/{thunk_64.S => thunk.S} (72%)
> delete mode 100644 arch/x86/entry/thunk_32.S
> create mode 100644 arch/x86/include/asm/rcu_preempt.h
>
>
> base-commit: f2f80ac809875855ac843f9e5e7480604b5cbff5
> --
> 2.19.1.6.gb485710b
>