All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Qiang1" <qiang1.zhang@intel.com>
To: "paulmck@kernel.org" <paulmck@kernel.org>
Cc: "frederic@kernel.org" <frederic@kernel.org>,
	"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] rcu-tasks: Check the atomic variable trc_n_readers_need_end again when wait timeout
Date: Thu, 31 Mar 2022 02:03:26 +0000	[thread overview]
Message-ID: <MW5PR11MB58585FA7332315F46FA36CD0DAE19@MW5PR11MB5858.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR11MB5880D6B11469266144C58032DA1F9@PH0PR11MB5880.namprd11.prod.outlook.com>


On Wed, Mar 30, 2022 at 07:20:14PM +0800, Zqiang wrote:
> When the trc_wait waitqueue timeout, the atomic variable 
> trc_n_readers_need_end need to be checked again, perhaps the 
> conditions have been established at this time, avoid invalid stall 
> information output.
>
>But are you actually seeing this invalid stall information?  Either way, please seem my comments and question below.
>
>Please don't get me wrong, we do have similar checks for normal vanilla RCU stall warnings, for example, this statement in print_other_cpu_stall() in kernel/rcu/tree_stall.h:
>
>	pr_err("INFO: Stall ended before state dump start\n");
>
>However, the approach used there did benefit from significant 
>real-world experience with its absence.  ;-)
>
>							Thanx, Paul
>
> Signed-off-by: Zqiang <qiang1.zhang@intel.com>
> ---
>  kernel/rcu/tasks.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 
> 65d6e21a607a..b73a2b362d6b 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -1544,7 +1544,7 @@ static void rcu_tasks_trace_postgp(struct rcu_tasks *rtp)
>  				trc_wait,
>  				atomic_read(&trc_n_readers_need_end) == 0,
>  				READ_ONCE(rcu_task_stall_timeout));

>If I understand correctly, this patch is intended to handle a situation where the wait_event_idle_exclusive_timeout() timed out, but where the value of trc_n_readers_need_end decreased to zero just at this point.
>>
>>Yes,  this patch is intended to handle a situation.

>If so, please see my question below.  If not, please show me the exact sequence of events leading up to the problem.

> -		if (ret)
> +		if (ret || !atomic_read(&trc_n_readers_need_end))
>  			break;  // Count reached zero.

>Couldn't the value of trc_n_readers_need_end decrease to zero right here, still resulting in invalid stall information?
>
>>The value of trc_n_readers_need_end decrease to zero right here, indicates that the current grace period has been completed.
>>Even if we go to print some task with condition 't->trc_reader_special.b.need_qs' as true,  and these task  will not affect the current grace period. Is my understanding correct?
>>

Is my commit  information not clear? Is this description more clearly

When the wait_event_idle_exclusive_timeout() timed out, if the value of
trc_n_readers_need_end  decrease to zero just at this point
this indicates that the current grace period is just completed at this point,
direct break  and  avoid printing stall information.


>>Thanks
>>Zqiang

>  		// Stall warning time, so make a list of the offenders.
>  		rcu_read_lock();
> --
> 2.25.1
> 

  reply	other threads:[~2022-03-31  2:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 11:20 [PATCH] rcu-tasks: Check the atomic variable trc_n_readers_need_end again when wait timeout Zqiang
2022-03-30 19:05 ` Paul E. McKenney
2022-03-30 22:30   ` Zhang, Qiang1
2022-03-31  2:03     ` Zhang, Qiang1 [this message]
2022-03-31 19:24       ` Paul E. McKenney
2022-04-01  0:23         ` Zhang, Qiang1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW5PR11MB58585FA7332315F46FA36CD0DAE19@MW5PR11MB5858.namprd11.prod.outlook.com \
    --to=qiang1.zhang@intel.com \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.