Received-SPF: pass (google.com: domain of linux-kernel+bounces-89319-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
References: <20240213055554.1802415-1-ankur.a.arora@oracle.com>
 <20240213055554.1802415-30-ankur.a.arora@oracle.com>
 <20240221164334.6f8c69e8@gandalf.local.home>
 <65e265e3.050a0220.7044b.19ad@mx.google.com>
User-agent: mu4e 1.4.10; emacs 27.2
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
        Ankur Arora
 <ankur.a.arora@oracle.com>, linux-kernel@vger.kernel.org,
        tglx@linutronix.de, peterz@infradead.org,
        torvalds@linux-foundation.org, paulmck@kernel.org,
        akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
        juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org,
        mgorman@suse.de, jpoimboe@kernel.org, mark.rutland@arm.com,
        jgross@suse.com, andrew.cooper3@citrix.com, bristot@kernel.org,
        mathieu.desnoyers@efficios.com, geert@linux-m68k.org,
        glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com,
        mattst88@gmail.com, krypton@ulrich-teichert.org,
        David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com,
        jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com,
        boris.ostrovsky@oracle.com, konrad.wilk@oracle.com,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Jonathan
 Corbet <corbet@lwn.net>
Subject: Re: [PATCH 29/30] Documentation: tracing: add TIF_NEED_RESCHED_LAZY
In-reply-to: <65e265e3.050a0220.7044b.19ad@mx.google.com>
Date: Fri, 01 Mar 2024 19:09:14 -0800
Message-ID: <87v8652uud.fsf@oracle.com>
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?VGYfR9Nxgk2d4TmFr69a7Kfl5/tjy/hVemjvRorQ8OeMqUnyi80tcv+7z1/D?=
 =?us-ascii?Q?tikm3KrDmiElYlqL6PT7GPVrC/BbZ4BF0XZgYdSMdU626zLjuhf3gTPKDbNj?=
 =?us-ascii?Q?qvEmG1GFow3lAvkvs+SqT176UKjWedG04E6bSMJiDihhtTz7fHF530Bwi9nk?=
 =?us-ascii?Q?Psw/sdZNC2Gxa+pZMaz2digMhTaaKuOCwqc/lTE36UJcD9odL28juJ7PggZz?=
 =?us-ascii?Q?dMGdB2YK9a8oq6OHk3kbqyRzyv5DwHqEBSMhix/Bb0uMAJDba0u+Ih6QvUv9?=
 =?us-ascii?Q?1ORlH9kgxcrZQptXrMRWnUlr7RMSVM8QbICGDktvuQc06CkoJ1392ZhK2ojO?=
 =?us-ascii?Q?gn32SdqVLcsvy0NVnWnJzYxlUcc9Qh8UMfPkZi+b137RyhZ8oOeYM7zcp+D5?=
 =?us-ascii?Q?uQOZGYkOPTcnQ6kJ2L4hROFyNChS/habcqZ3BhlkLygWObndvnhYlKTYZ8U8?=
 =?us-ascii?Q?LKiRSw821/LCTI3mYvsOh7xJaaFoRG3i2NTpqRyMjpjd0s4cIC1GdKvbGmsg?=
 =?us-ascii?Q?GEWCZNM94oKn8HxAsevjjCtwjFF5IXJ3nixIgkLvpgN7dTS5imeiaGeE9QoX?=
 =?us-ascii?Q?V4cE6TDeq1zNFzYz1HjKZxwK3InHLhzQeYfWbt6zfY+ZPxrJvnaFoGYIzEoq?=
 =?us-ascii?Q?iow6/uTDTRq4py0JvVz38vc9xa2iByuFaiHUdGcNHwpsYXz8E/iJla9CzXIS?=
 =?us-ascii?Q?hLAcJTAXdMzzwps83jw9qHHLUboLJFObFHLe0w7ptwhqqBBRRlFACWR7PFR/?=
 =?us-ascii?Q?PZfSg2fJA2Rj9L9GJ57UyqFu123o3HlBKkcu6KRS7bFTxT8ml1CVg7lj0yXT?=
 =?us-ascii?Q?giUaWec8pxUbmIqM0RyddmFON/gmTOTpcrTgzC/A6KIfofDYqgdbCsRgwS/Z?=
 =?us-ascii?Q?Zdk8KvLaOQ4l7XBS8CI0UXGUgb5X6O1esB6Orcf0/Pq88fPmqKYU9V78//hb?=
 =?us-ascii?Q?uppMR7npa0j8cHqcrWRREDR/5VKO2EEzuBEAcMAa7Zpv5oJ0WPC2igddraUr?=
 =?us-ascii?Q?4Agv2pLFU90K3TBYU7XVfZmSpgbvOPwt6fPa4FeAhtdiwGJasii77JOn4aEp?=
 =?us-ascii?Q?T5OZagfXevP69GCJc95pCV4WTVHwNhSv8+HjSy8aTXrWP6oM08u5KZsxTvLc?=
 =?us-ascii?Q?6A9Tp0cLJLjl9Ph2aDtARsxkW1czhRgt3MwrSccb/WOxbudMk8FJRByvxgFe?=
 =?us-ascii?Q?k0YfZlx7Xm+CesxzECGNYtkLMnEAM5KhXuwqyxw/dwgo6YQBear1V24MS5PU?=
 =?us-ascii?Q?9Lvj35fRBQtp/Ku+Fmj/q9jjaOTqcRurvQ5nDFku/D05mobPFcZn/tNbOG/2?=
 =?us-ascii?Q?3dBKSBnSX02BPaLYrDdOxxE2RGERHBmQTHS3SA9o1+4sjQqZcsPy24//q9kd?=
 =?us-ascii?Q?zVYwayzHOKpL7ER/vc9Z0CLGqjvQm0bVVfMyfWxEsbyRPRMLNdInMv9NaD7Z?=
 =?us-ascii?Q?tDb5/spagwp7IvQGbIbFE3KbUYrxdnCj/1WyTSmIrg9xmK9f5wH2hcEE83UV?=
 =?us-ascii?Q?imtT/cBfB42nTxBCHavzP66WeS6YUnBTw+hxqicGRCpK1uDeV11/7C1dw7pt?=
 =?us-ascii?Q?UavJItACAW3UzPWnUyHeocg6FqguVVNtglaO+2q9nCpyGyNFOmwecCLLPPNj?=
 =?us-ascii?Q?lg=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	Vf0S/XpMzSsCXii+Rjx4BRpeXlZ9XGcYJ0Knu9D03pE/iEolN/YYaeZI3IroZ11njVmDozGeObdUdqzRAUbrmyfiRF1yC6KsWXWVMO6amZLCTYiUiZqSXmbLnhu/VoUtRiSsGdFpHqKGLu+LAlzSJ2V9eHANTxR4whXBj1wEmO+qyULhjhKwbRGt83uDhEsclq+OUCM+jOlc0utabLnsZuI4oKlxuRs+7A32pdUpiMncj6Xywhg2gadanKQMzwqYDwMyVbZ06xB01gA8eVw8sbN8jiqIxPh/E7GMuzfdQ851bZOVLyvl/iLn1JGHBVDdmLr8xdagcIov0G1vVBQwVQh01wrV6hvhXEZXVNZzjIbT4OdiT75W/9sPPbe7k1hcEdGM8T/mWQych1NTm73p880n/RZtH1RT6cG2hHHEHZwZTPtTTlcnxsGxutmKxj8GKvgzkys7sJqdkAW8C+733bt1i2nXDimgW8Rf48Ob/G9tfYXPyIXanK/xHFemtfQEhTOJsEEutUvkrSRg3nrheBrJ6lHxVK0Qc89y7s2jQ/vKCQk6BkmUFb0jLHkuUTD7AeGr3ohHYe3SaFztaJJcoxcggb5y2LGu7kVIUzs+bRI=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a5f8ffd-d5b0-4017-6e5e-08dc3a661411
X-MS-Exchange-CrossTenant-AuthSource: CO6PR10MB5409.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2024 03:08:47.9866
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UZ4HL4hfMcrSahjQ16RC14SDRKzYD6dutTW1pZsUqNeKOOHTnbWZtidcR6RQ8dZpDHXZpubcaM/cWv03xoD5y9EmvQzqfTxJJNhv1dPjyyc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB6853
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-01_24,2024-03-01_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999
 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 bulkscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2403020025
X-Proofpoint-ORIG-GUID: d_gVU6c5VKsL5Rq3Z1nG38ztq3og6FsM
X-Proofpoint-GUID: d_gVU6c5VKsL5Rq3Z1nG38ztq3og6FsM


Joel Fernandes <joel@joelfernandes.org> writes:

> On Wed, Feb 21, 2024 at 04:43:34PM -0500, Steven Rostedt wrote:
>> On Mon, 12 Feb 2024 21:55:53 -0800
>> Ankur Arora <ankur.a.arora@oracle.com> wrote:
>>
>> > Document various combinations of resched flags.
>> >
>> > Cc: Steven Rostedt <rostedt@goodmis.org>
>> > Cc: Masami Hiramatsu <mhiramat@kernel.org>
>> > Cc: Jonathan Corbet <corbet@lwn.net>
>> > Originally-by: Thomas Gleixner <tglx@linutronix.de>
>> > Link: https://lore.kernel.org/lkml/87jzshhexi.ffs@tglx/
>> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> > ---
>> >  Documentation/trace/ftrace.rst | 6 +++++-
>> >  1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
>> > index 7e7b8ec17934..7f20c0bae009 100644
>> > --- a/Documentation/trace/ftrace.rst
>> > +++ b/Documentation/trace/ftrace.rst
>> > @@ -1036,8 +1036,12 @@ explains which is which.
>> >  		be printed here.
>> >
>> >    need-resched:
>> > -	- 'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set,
>> > +	- 'B' all three, TIF_NEED_RESCHED, TIF_NEED_RESCHED_LAZY and PREEMPT_NEED_RESCHED are set,
>> > +	- 'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED are set,
>> > +	- 'L' both TIF_NEED_RESCHED_LAZY and PREEMPT_NEED_RESCHED are set,
>> > +	- 'b' both TIF_NEED_RESCHED and TIF_NEED_RESCHED_LAZY are set,
>> >  	- 'n' only TIF_NEED_RESCHED is set,
>> > +	- 'l' only TIF_NEED_RESCHED_LAZY is set,
>> >  	- 'p' only PREEMPT_NEED_RESCHED is set,
>
> One thing I was curious about in current code, under which situation will
> "only PREEMPT_NEED_RESCHED is set" case happen? All the code paths I see set
> the PREEMPT_NEED_RESCHED when then TIF has already been set. That kind of
> makes sense, why enter the scheduler on preempt_enable() unless there was a
> reason to, and TIF should have recorded that reason.

True. And, the only place where we clear PREEMPT_NEED_RESCHED is in
__schedule() after clearing the TIF_NEED_RESCHED* flags.

> So in other words, if 'p' above cannot happen, then it could be removed as a
> potential need-resched stat. If it can happen, I'd love to learn in which
> case?

Yeah, AFAICT the only case we might see it alone is in case of a bug.

> Also considering all users of set_tsk_need_resched() also call the
> set_preempt_need_resched() shortly after, should we add a helper to squash
> the 2 calls and simplify callers?
>
Just to explicitly lay out the reason for these being separate interfaces:
set_tsk_need_resched() can be set from a remote CPU, while
set_preempt_need_resched() (or its folding version) is only meant to be
used on the local CPU.

> There are some "special cases" where only TIF flag need be set (such as setting
> rescheduling from an interrupt or when rescheduling a remote CPU). For those,
> they can directly call the set_tsk_need_resched() like they do now.

The remote case, as you say is always handled in the scheduler. So, maybe
it is worth having a set_need_resched_local_cpu() which takes care of
both of these things but more importantly makes clear the limits of this.

That said, these interfaces have very few users (just RCU, and the s390
page fault handler) and both of these are fairly sophisticated users, so
not sure yet another interface in this area is worth adding.

Thanks

--
ankur