rcu: use __this_cpu_read helper instead of per_cpu_ptr(p, raw_smp_processor_id())
PATCH v3 6/9 rcu: use __this_cpu_read helper instead of per_cpu_ptr(p, raw_smp_processor_id())
From: Shan Wei <[email protected]>
---
no changes vs v3,v2.
--- kernel/rcutree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
kernel/rcutree.c +1 -1
@@ -1960,7 +1960,7 @@ static void force_quiescent_state(struct rcu_state *rsp)struct rcu_node *rnp_old =NULL ;/* Funnel through hierarchy to reduce memory contention. */ - rnp =per_cpu_ptr (rsp->rda,raw_smp_processor_id ())->mynode; + rnp =__this_cpu_read (rsp->rda->mynode);for (; rnp !=NULL ; rnp = rnp->parent) { ret = (ACCESS_ONCE (rsp->gp_flags) &RCU_GP_FLAG_FQS ) || !raw_spin_trylock (&rnp->fqslock);
Signature · 1 line
1.7.1
Shan Wei said, at 2012/11/13 9:52:
Quoted 4 lines
From: Shan Wei <[email protected]>
Signed-off-by Shan Wei <[email protected]>
Paul, would you like to pick it up to your tree?
Quoted 20 lines
---
no changes vs v3,v2.--- kernel/rcutree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)kernel/rcutree.c +1
-1@@ -1960,7 +1960,7 @@ static void force_quiescent_state(struct rcu_state *rsp)struct rcu_node *rnp_old =NULL ;/* Funnel through hierarchy to reduce memory contention. */ - rnp =per_cpu_ptr (rsp->rda,raw_smp_processor_id ())->mynode; + rnp =__this_cpu_read (rsp->rda->mynode);for (; rnp !=NULL ; rnp = rnp->parent) { ret = (ACCESS_ONCE (rsp->gp_flags) &RCU_GP_FLAG_FQS ) || !raw_spin_trylock (&rnp->fqslock);
Quoted 7 lines · Shan Wei
Shan Wei said, at 2012/11/13 9:52:
Quoted 4 lines
From: Shan Wei <[email protected]>
Signed-off-by Shan Wei <[email protected]>Paul, would you like to pick it up to your tree?
Hello, Shan Wei,
If you either show me some significant performance benefits or get me an independent Tested-by, in both cases on a range of hardware (e.g., x86 on the one hand and ARM or Power on the other), then I will queue it.
I wasn't prioritizing this one very high because it does not appear to be on any sort of fastpath. If I am wrong about that, then you have a good performance-benefit case, right? ;-)
Thanx, Paul
Quoted 21 lines
Quoted 20 lines
---
no changes vs v3,v2.--- kernel/rcutree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)kernel/rcutree.c +1
-1@@ -1960,7 +1960,7 @@ static void force_quiescent_state(struct rcu_state *rsp)struct rcu_node *rnp_old =NULL ;/* Funnel through hierarchy to reduce memory contention. */ - rnp =per_cpu_ptr (rsp->rda,raw_smp_processor_id ())->mynode; + rnp =__this_cpu_read (rsp->rda->mynode);for (; rnp !=NULL ; rnp = rnp->parent) { ret = (ACCESS_ONCE (rsp->gp_flags) &RCU_GP_FLAG_FQS ) || !raw_spin_trylock (&rnp->fqslock);
Quoted 3 lines · Paul E. McKenney
If you either show me some significant performance benefits or get me an independent Tested-by, in both cases on a range of hardware (e.g., x86 on the one hand and ARM or Power on the other), then I will queue it.
Just putting the code generated for x86 before and after side by side would be enough to convince you I think.
Quoted 3 lines
I wasn't prioritizing this one very high because it does not appear to be on any sort of fastpath. If I am wrong about that, then you have a good performance-benefit case, right? ;-)
I do not think this needs to be a priority item. Just stick it in the tree somewhere to merge for the next merge period.
Quoted 9 lines · Christoph Lameter
Quoted 3 lines · Paul E. McKenney
If you either show me some significant performance benefits or get me an independent Tested-by, in both cases on a range of hardware (e.g., x86 on the one hand and ARM or Power on the other), then I will queue it.
Just putting the code generated for x86 before and after side by side would be enough to convince you I think.
If accompanied by similar before/after code for ARM or Power, sure.
Thanx, Paul
Quoted 7 lines
Quoted 3 lines
I wasn't prioritizing this one very high because it does not appear to be on any sort of fastpath. If I am wrong about that, then you have a good performance-benefit case, right? ;-)
I do not think this needs to be a priority item. Just stick it in the tree somewhere to merge for the next merge period.