Received-SPF: pass (google.com: domain of linux-kernel+bounces-73757-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-4-ankur.a.arora@oracle.com>
 <ZczJU8uZdbRKvcAE@FVFF77S0Q05N> <87v86k8opr.ffs@tglx>
User-agent: mu4e 1.4.10; emacs 27.2
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
        Ankur Arora
 <ankur.a.arora@oracle.com>, linux-kernel@vger.kernel.org,
        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,
        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, rostedt@goodmis.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,
        Arnd Bergmann
 <arnd@arndb.de>,
        "Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 03/30] thread_info: tif_need_resched() now takes
 resched_t as param
In-reply-to: <87v86k8opr.ffs@tglx>
Date: Tue, 20 Feb 2024 14:21:16 -0800
Message-ID: <877ciykc9v.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?kCYeTnhsJIx3CNALPYJV7HVDcjFXTx09pKaJ/zOjqI9d2Fo5gw34nR8KPHqR?=
 =?us-ascii?Q?1kxZ3mYuyxUfiPUoG7M7Js5Vn27IFU788XfNJnYb2fsGcDNfp9Ou4O5ZVkRo?=
 =?us-ascii?Q?Pdp/TPWejd2zb18cSLoedP5tfOZdVbgaIwC/xBKkWdeb/DvLapPEJo2SoEnZ?=
 =?us-ascii?Q?WWEurqSqqNFOkKS3GhCRSHQRecRIZl2zrnMbJii2diIpq1nrtC/DGj8XRqd7?=
 =?us-ascii?Q?L4psLCAVOIc3GEc0OTaetnrd2WWrhWT7aeVUc5lZ1kL8V9ONKtFOaJVyYURm?=
 =?us-ascii?Q?KMVKvK9JwQWpMWSEARPSZNV01RJ+kBX7dR4iOki+UoaZcbZJoffoSQ/esUFQ?=
 =?us-ascii?Q?wv6jVY524roApwBN4nFEGbaM2GvID5PqVcgSDvTDNQXC0PGK+/viVl3XEQYW?=
 =?us-ascii?Q?7+wwQgZu6mXX/OOLhuR0gmvT1r3/9QJmzp2SzsmrbDVSgth8HU64KIuZKPb9?=
 =?us-ascii?Q?KNQ2ciJHj+rhfXCsOrdY84vY/pBqVXkUsVHkd8N6cQeqCRpgwY9byLPVDQ5+?=
 =?us-ascii?Q?81JRaopsV+3bTf2B7p479rxP6PUZi1fGVCg6JhVuRFV8xhN3pzt6jJQwdIHg?=
 =?us-ascii?Q?GsA9lJjA4lH7ku4kjItYHq5Mh07HAYFKsNCN98f1Oh8/yRzeEUTJXLjdVRTV?=
 =?us-ascii?Q?hSmXzuGo9FbEq4iKEMBqZpknFjVmIQh54OoVyX9JsGg34a/24/682K88vdu2?=
 =?us-ascii?Q?QXuAeKu3mZ/72iYR2Ac+5WbajMhDIOENwM/sxS8e/Wju0sVlOWxbI6gdJIv5?=
 =?us-ascii?Q?ZzWdmi8FxWJWWMKR4uMI0VJ+carw/nJL+6n0N4IuE2mLcFhEXW+6gnpCRsfq?=
 =?us-ascii?Q?7gKkl2AMKVBiFeHmdkAIzRigwP4Zu4iWxzl6S1gwKDZjU3YwfTjek4c4aDFk?=
 =?us-ascii?Q?7v6+YIu95n4ZowRRwPuXHTwmD5+2QPfA/GW6XAV9QvYiFl4nUDu3x8kb/48x?=
 =?us-ascii?Q?3p7Kbw4p2RLh+exjLI2oDnJrEeopAlp/FsdrIX7y8hjos9o1yriGC7fH+Efj?=
 =?us-ascii?Q?eT/xDWigC94516aQYyRnPfq18ctq/LQ/FwambKV3+N/vEXQO7JTaXlFxiIwN?=
 =?us-ascii?Q?YAsxrEUQ8bUShVWZXyqBvdmVO54/MKYIgEZpED3F3zDYDdY9A2clLkugIBCH?=
 =?us-ascii?Q?gfriH+4gDDGit+PAy5Lmo8VF1Gy6VMwFlISVI+3rx0EaVCCIOH9titk5gMyK?=
 =?us-ascii?Q?fwIIdU0vW68uqZXCUWb0rF7kmb1Ikcytv4pxQmQhOzIz7AvIMDh/hxDUjsB2?=
 =?us-ascii?Q?ozVcpptZUotO3DeMtXRMk2kXMkGYpWWxSyRNqttUFyIPBYWpBT7o0un2unOT?=
 =?us-ascii?Q?/+7zWPVhPAuAadSDEWliYDABv5FPKdO3wbl/VSQLNv38M+LeZqKN1sWrw2h3?=
 =?us-ascii?Q?TZwbZoTKysZw7z28mOOX7ipF4QpLTnx7UvUlE1IMXNG1ACNA/DCYIu26+QvD?=
 =?us-ascii?Q?V17JWKbYiIxCRdhubG8N3P42CcNebOwwvTS2Z1A+QHK/z+EJIRyB+Oe5Qexw?=
 =?us-ascii?Q?dMcFgd8u1FIm9JbraJWMfw1xtL4YAer0S/IVGc8BlHnL87ENX45fhVbygV9l?=
 =?us-ascii?Q?lXyO8Rm2XoXlbIK5rhre96Z97wQ1xwncCyI4E9OgjtOKKyV9VXyQYUyyjbw5?=
 =?us-ascii?Q?+A=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	5JiUz2gGu9C7rvh6wgU5ZQD4ndA1NVVN79ufBIOTz27J1qN8NwUZQQAXkxFFmix+68d2SPdCVAmY8SvJdbqF6iwk3mcl/vmBk1eYBiBTtYj5e6BzXIcMQKxFJX3Xi31JbxNUo8uDwROGSm/v/Z9k1t2G8tNMf5twvEeMU8FoEuH0v2x7ienBPEeXF7wcRPSl0h/OkOR01P5GphqWffN9+V09YDKuNelRi3bsx+AP0vsKpOe5wpQGXicimp3/DbQpMmMFe0HpROO3xry1xYDgG7vSRAmjEE4cYsiWYsEG0pMW80JwgP16g/j+sU5JFWjJcFu83fPSNbHnOL5A8v99q9pWh6tftmBIOS+Usg3l3vB6TXAsvnUNa9o9JWL2sBTqsBXCyAOzARxwxsxXURkhOC0T2SwZBQJYZIOP7YRgKF0q8LfpPvAyaznJF1bl2L3seYfi/LKQ84cTluvM6nPELHSBfD6d9hnqizxmaT98yFfFA0OKxbX16gtrmS/v/8OLBIDXO6d9KoCEHvW6q80rosoGl9MxhnWaBHNH+1Gkq29u+Cmzj4M2GrbSt0WIAmSGhJhxWdXONovLBfgFB2fD3S5HZjKSGeN4sS8r73MlmHs=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f6f930e9-974a-4a65-92d7-08dc326233bc
X-MS-Exchange-CrossTenant-AuthSource: CO6PR10MB5409.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2024 22:20:53.7583
 (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: V+c6yFl5cG2mO8R64YxqyfDsH+nihQKBELC7rk5bKiYbdTjXF7G3YDTj6GG8TopMWGZikbFlIjxBWsTQlCsZ04z6XuNia16xOyrnX3r46EU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB5883
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-02-20_06,2024-02-20_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 mlxscore=0 mlxlogscore=915 adultscore=0 bulkscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2402200161
X-Proofpoint-ORIG-GUID: ngQfYKIMa52U5CFFUT_s_YETUvIExUFi
X-Proofpoint-GUID: ngQfYKIMa52U5CFFUT_s_YETUvIExUFi


Thomas Gleixner <tglx@linutronix.de> writes:

> On Wed, Feb 14 2024 at 14:08, Mark Rutland wrote:
>> On Mon, Feb 12, 2024 at 09:55:27PM -0800, Ankur Arora wrote:
>>>
>>> -static __always_inline bool tif_need_resched(void)
>>> +static __always_inline bool __tif_need_resched(int nr_flag)
>>>  {
>>> -	return test_bit(TIF_NEED_RESCHED,
>>> -			(unsigned long *)(&current_thread_info()->flags));
>>> +	return test_bit(nr_flag,
>>> +		(unsigned long *)(&current_thread_info()->flags));
>>>  }
>>>
>>>  #endif /* _ASM_GENERIC_BITOPS_INSTRUMENTED_NON_ATOMIC_H */
>>>
>>> +static __always_inline bool tif_need_resched(resched_t rs)
>>> +{
>>> +	/*
>>> +	 * With !PREEMPT_AUTO tif_need_resched(NR_lazy) is defined
>>> +	 * as TIF_NEED_RESCHED (the TIF_NEED_RESCHED_LAZY flag is not
>>> +	 * defined). Return false in that case.
>>> +	 */
>>> +	if (IS_ENABLED(CONFIG_PREEMPT_AUTO) || rs == NR_now)
>>> +		return __tif_need_resched(tif_resched(rs));
>>> +	else
>>> +		return false;
>>> +}
>>
>> As above, I think this would be a bit simpler/clearer if we did:
>>
>> static __always_inline bool tif_need_resched_now(void)
>> {
>> 	return __tif_need_resched(TIF_NEED_RESCHED);
>> }
>>
>> static __always_inline bool tif_need_resched_lazy(void)
>> {
>> 	return IS_ENABLED(CONFIG_PREEMPT_AUTO) &&
>> 	        __tif_need_resched(TIF_NEED_RESCHED_LAZY);
>> }
>
> Yes please.

As I wrote to Mark in the sibling subthread, I think exposing
the lazy variants outside of the scheduler isn't really needed.

Non-scheduler/non-entry code only cares about checking if it needs
to do reschedule now. So, I think we can get away with just having:

    static __always_inline bool __tif_need_resched(resched_t rs)
    {
            /*
            * With !PREEMPT_AUTO tif_need_resched(NR_lazy) is defined
            * as TIF_NEED_RESCHED (the TIF_NEED_RESCHED_LAZY flag is not
            * defined). Return false in that case.
            */
            if (IS_ENABLED(CONFIG_PREEMPT_AUTO) || rs == NR_now)
                    return tif_need_resched_bitop(tif_resched(rs));
            else
                    return false;
    }

    static __always_inline bool tif_need_resched(void)
    {
            return __tif_need_resched(NR_now);
    }

(and similar for all the other interfaces.)

This way lazy and eager just becomes an implementation detail which
which seems to also match nicely to the point of PREEMPT_AUTO.

--
ankur