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


Groups > linux.kernel > #1706770 > unrolled thread

[PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

Started byNeeraj Upadhyay <neeraju@codeaurora.org>
First post2017-08-08 19:30 +0200
Last post2017-08-09 00:00 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set Neeraj Upadhyay <neeraju@codeaurora.org> - 2017-08-08 19:30 +0200
    Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is  set "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-08-08 20:10 +0200
      Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is  set Neeraj Upadhyay <neeraju@codeaurora.org> - 2017-08-08 21:00 +0200
        Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is  set "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-08-09 00:00 +0200

#1706770 — [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

FromNeeraj Upadhyay <neeraju@codeaurora.org>
Date2017-08-08 19:30 +0200
Subject[PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set
Message-ID<ucgul-37R-1@gated-at.bofh.it>
If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall()
does checks to figure out whether jiffies is past rsp->jiffies_stall,
doing ordered accesses to avoid any false positives for new grace
period initialization after a sufficiently large idle period. This
extra processing can be skipped if rcu_cpu_stall_suppress is set.

Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS")
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
---
 kernel/rcu/tree.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 51d4c3a..91b7552 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
 	unsigned long js;
 	struct rcu_node *rnp;
 
-	if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) ||
-	    !rcu_gp_in_progress(rsp))
+	if (!rcu_gp_in_progress(rsp))
 		return;
 	rcu_stall_kick_kthreads(rsp);
+
+	if (rcu_cpu_stall_suppress)
+		return;
+
 	j = jiffies;
 
 	/*
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation

[toc] | [next] | [standalone]


#1706787 — Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-08-08 20:10 +0200
SubjectRe: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set
Message-ID<uch73-3Ae-9@gated-at.bofh.it>
In reply to#1706770
On Tue, Aug 08, 2017 at 10:50:26PM +0530, Neeraj Upadhyay wrote:
> If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall()
> does checks to figure out whether jiffies is past rsp->jiffies_stall,
> doing ordered accesses to avoid any false positives for new grace
> period initialization after a sufficiently large idle period. This
> extra processing can be skipped if rcu_cpu_stall_suppress is set.

Just to make sure I understand, the concern is that someone might have
booted with rcupdate.rcu_cpu_stall_suppress=1 (thus suppressing the RCU
CPU stall debugging warnings implemented later in check_cpu_stall()),
but later decided to also boot with rcutree.rcu_kick_kthreads=1 (thus
enabling kicking kthreads which check for RCU's grace-period kthreads
not being properly awakened)?

My immediate reaction is that if there is not much point in specifying
both rcutree.rcu_kick_kthreads=1 and rcupdate.rcu_cpu_stall_suppress=1.
But is there some use case that I am missing?

							Thanx, Paul

> Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS")
> Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
> ---
>  kernel/rcu/tree.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 51d4c3a..91b7552 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
>  	unsigned long js;
>  	struct rcu_node *rnp;
> 
> -	if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) ||
> -	    !rcu_gp_in_progress(rsp))
> +	if (!rcu_gp_in_progress(rsp))
>  		return;
>  	rcu_stall_kick_kthreads(rsp);
> +
> +	if (rcu_cpu_stall_suppress)
> +		return;
> +
>  	j = jiffies;
> 
>  	/*
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of the Code Aurora Forum, hosted by The Linux Foundation
> 

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


#1706830 — Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

FromNeeraj Upadhyay <neeraju@codeaurora.org>
Date2017-08-08 21:00 +0200
SubjectRe: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set
Message-ID<uchTt-3SV-37@gated-at.bofh.it>
In reply to#1706787

On 08/08/2017 11:32 PM, Paul E. McKenney wrote:
> On Tue, Aug 08, 2017 at 10:50:26PM +0530, Neeraj Upadhyay wrote:
>> If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall()
>> does checks to figure out whether jiffies is past rsp->jiffies_stall,
>> doing ordered accesses to avoid any false positives for new grace
>> period initialization after a sufficiently large idle period. This
>> extra processing can be skipped if rcu_cpu_stall_suppress is set.
> Just to make sure I understand, the concern is that someone might have
> booted with rcupdate.rcu_cpu_stall_suppress=1 (thus suppressing the RCU
> CPU stall debugging warnings implemented later in check_cpu_stall()),
> but later decided to also boot with rcutree.rcu_kick_kthreads=1 (thus
> enabling kicking kthreads which check for RCU's grace-period kthreads
> not being properly awakened)?
>
> My immediate reaction is that if there is not much point in specifying
> both rcutree.rcu_kick_kthreads=1 and rcupdate.rcu_cpu_stall_suppress=1.
> But is there some use case that I am missing?
>
> 							Thanx, Paul
For boot time configuration, agree, there isn't much point in enabling
both options. In addition to boot time, rcu_cpu_stall_suppress can
be temporarily enabled during some operations like sysrq; but this may
not be a use case worth consideration.
>
>> Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS")
>> Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
>> ---
>>   kernel/rcu/tree.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>> index 51d4c3a..91b7552 100644
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
>>   	unsigned long js;
>>   	struct rcu_node *rnp;
>>
>> -	if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) ||
>> -	    !rcu_gp_in_progress(rsp))
>> +	if (!rcu_gp_in_progress(rsp))
>>   		return;
>>   	rcu_stall_kick_kthreads(rsp);
>> +
>> +	if (rcu_cpu_stall_suppress)
>> +		return;
>> +
>>   	j = jiffies;
>>
>>   	/*
>> -- 
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of the Code Aurora Forum, hosted by The Linux Foundation
>>

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation

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


#1706901 — Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2017-08-09 00:00 +0200
SubjectRe: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set
Message-ID<uckHE-64i-23@gated-at.bofh.it>
In reply to#1706830
On Wed, Aug 09, 2017 at 12:27:16AM +0530, Neeraj Upadhyay wrote:
> 
> 
> On 08/08/2017 11:32 PM, Paul E. McKenney wrote:
> >On Tue, Aug 08, 2017 at 10:50:26PM +0530, Neeraj Upadhyay wrote:
> >>If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall()
> >>does checks to figure out whether jiffies is past rsp->jiffies_stall,
> >>doing ordered accesses to avoid any false positives for new grace
> >>period initialization after a sufficiently large idle period. This
> >>extra processing can be skipped if rcu_cpu_stall_suppress is set.
> >Just to make sure I understand, the concern is that someone might have
> >booted with rcupdate.rcu_cpu_stall_suppress=1 (thus suppressing the RCU
> >CPU stall debugging warnings implemented later in check_cpu_stall()),
> >but later decided to also boot with rcutree.rcu_kick_kthreads=1 (thus
> >enabling kicking kthreads which check for RCU's grace-period kthreads
> >not being properly awakened)?
> >
> >My immediate reaction is that if there is not much point in specifying
> >both rcutree.rcu_kick_kthreads=1 and rcupdate.rcu_cpu_stall_suppress=1.
> >But is there some use case that I am missing?
> >
> >							Thanx, Paul
> For boot time configuration, agree, there isn't much point in enabling
> both options. In addition to boot time, rcu_cpu_stall_suppress can
> be temporarily enabled during some operations like sysrq; but this may
> not be a use case worth consideration.

OK, I will skip this one, for the time being at least.  But thank you
for your review and patches!

							Thanx, Paul

> >>Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS")
> >>Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
> >>---
> >>  kernel/rcu/tree.c | 7 +++++--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> >>index 51d4c3a..91b7552 100644
> >>--- a/kernel/rcu/tree.c
> >>+++ b/kernel/rcu/tree.c
> >>@@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
> >>  	unsigned long js;
> >>  	struct rcu_node *rnp;
> >>
> >>-	if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) ||
> >>-	    !rcu_gp_in_progress(rsp))
> >>+	if (!rcu_gp_in_progress(rsp))
> >>  		return;
> >>  	rcu_stall_kick_kthreads(rsp);
> >>+
> >>+	if (rcu_cpu_stall_suppress)
> >>+		return;
> >>+
> >>  	j = jiffies;
> >>
> >>  	/*
> >>-- 
> >>QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >>member of the Code Aurora Forum, hosted by The Linux Foundation
> >>
> 
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of the Code Aurora Forum, hosted by The Linux Foundation
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web