Received-SPF: pass (google.com: domain of linux-kernel+bounces-137562-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 9 Apr 2024 12:53:03 -0700
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Valentin Schneider <vschneid@redhat.com>, rcu@vger.kernel.org,
	linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>
Subject: Re: [PATCH 2/2] context_tracking, rcu: Rename RCU_DYNTICKS_IDX to
 CT_DYNTICKS_IDX
Message-ID: <1ef9d1f9-16a2-4ddc-abd5-6c3b7cde290f@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <20240327112902.1184822-1-vschneid@redhat.com>
 <20240327112902.1184822-3-vschneid@redhat.com>
 <Zg6tYD-9AFPkOOsW@localhost.localdomain>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Zg6tYD-9AFPkOOsW@localhost.localdomain>

On Thu, Apr 04, 2024 at 03:38:40PM +0200, Frederic Weisbecker wrote:
> Le Wed, Mar 27, 2024 at 12:29:02PM +0100, Valentin Schneider a ?crit :
> > The symbols relating to the CT_STATE part of context_tracking.state are now
> > all prefixed with CT_STATE.
> > 
> > The RCU dynticks counter part of that atomic variable still involves
> > symbols with different prefixes, align them all to be prefixed with
> > CT_DYNTICKS, as CT_DYNTICKS_MASK already is.
> > 
> > Signed-off-by: Valentin Schneider <vschneid@redhat.com>
> 
> It used to be that RCU extended quiescent state and dynticks enter/exit
> were coupled. But this isn't the case anymore. Nowadays RCU stops watching
> some time later after dynticks is entered.

I knew that consolidation of atomic operations was too good to last...

> I wonder if we shouldn't take advantage of that cleanup for a meaning that
> really reflect that RCU stops watching from there.
> 
> Paul what do you think? CT_EQS_IDX ? CT_RCUEQS_IDX? CT_RCUOFF_IDX? ...?

"After what you just did?  You can just RCU off!!!"

Sorry, couldn't resist...

I am having a hard time getting too excited about the name.  I could
suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest
possible name.

							Thanx, Paul