From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011021.outbound.protection.outlook.com [40.107.208.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43DB21E5702 for ; Tue, 17 Mar 2026 05:41:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.21 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773726098; cv=fail; b=APtoIpbzCgFsh8rhz2vtOQO1bgZpl6fD6hXchblEmXQ7fZggoqp/O2xPowVd2SI/67Y8RcN86sqT2CG5tee1hFcWqLAMvzYAdG6S3ybRRYJFXYExlt5mhdSswYJDhr/bKfw3ntti9vPAOQTj/KxKTk5IfeknymJQgtpR9oRQItE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773726098; c=relaxed/simple; bh=Wwmguo6ArIYk4IdYTkIbKNJi8dDuGJT8UwYhS696eUA=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=WOKCVcxr7DROlHLanlAOjiwqZJadliNYYZkDF/Cy5z7ft+Uax4SYcLZ6ERj5ZxKtPuT9VQzhkFP25AfTQEs2xjFuFLHRvEQCIXl7wawOPy7N8MZaZB09F1XdKrpTYnQGS+gEe1C1532YMoi2u1UzPmLQlWfTH7A2D4ei3ziWPSU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=RuY3YWqD; arc=fail smtp.client-ip=40.107.208.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="RuY3YWqD" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=asDw4CGAMdVZNdWxz5eWE0crdm8eQKzT0LHdpDFnmpavrZHzzaiq0Z7pNBiN0WJ+cSLlah3nlVt8kIXE3+D6Ff3G90YKghqfOPdmxb6pIdXSR7EwNPhA2sVccezXy4d17s13O0n4IEUjo0VizytUlcC7dByhB0R6mUrRO76XYwAbnW8WrCs5/IDCUPu/06Qsrn68/3lbIk2bFT+f7kHfneXk2gTxAA5NQZeQkUY+AWoyYVIy6zGG/ItoqjdD0swsnF+nhRPiGi5reRBnbEOMuZPS/v/n6PIeQOoF5zRF4aLu0I1hObYob60FbVTCtlup+SxTg95Kalu/bK3xmn3CPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RJ+SNG7A5GYKOF4VoGoEgmrxRaO9B1fpkuSWiBQJ/Ds=; b=LHPqvRzsNGne/2D9QdTj8Pz93a70LDBvtL5Xk/TcV+k472MvXW6/V1y1PZXoEPH4+gkYf2GX1Ah+blLQUTaJptCx6xm+nsnmOQ+pJguLk+hysttw5oUk3b7IGImeWfZ27t20m7ayFbL6a+FHrbz6cXunv7UXG++F8h5OGzkcYQE3RCGPMpq1va7kjjU/4H4SH8MFDYu9wJwXAjF1zcJC7NZ1yySnFGGOd2wG6p+EMnK0yp+Saxf2+zVfZZ1ZbSdTuFTj9H+2AwhHmFETy/sMiUQMe6fQItmuLPnxYrHM1vVvQHLq4EiTls+L6H2ptHEOZ59smX8hrQCF5/mNAhpFxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=google.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RJ+SNG7A5GYKOF4VoGoEgmrxRaO9B1fpkuSWiBQJ/Ds=; b=RuY3YWqDJ763PDC0n1/pgK6SqHFkHy+RMpm9+Mh0lZlCDVOVTZvrWsLR2rm+0d6MtBHCD8wvCmggBxdmazKSL+HG2zx6jZfiSk83XUhbBRxoshS3+uB0w95YB7BM1c1sAk+PzQq4xbR+BzPT4ZZ81QicBP+oBecVk7ysDRcdwUg= Received: from CH0PR03CA0195.namprd03.prod.outlook.com (2603:10b6:610:e4::20) by CY8PR12MB8066.namprd12.prod.outlook.com (2603:10b6:930:70::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.17; Tue, 17 Mar 2026 05:41:32 +0000 Received: from CH1PEPF0000A347.namprd04.prod.outlook.com (2603:10b6:610:e4:cafe::9d) by CH0PR03CA0195.outlook.office365.com (2603:10b6:610:e4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.25 via Frontend Transport; Tue, 17 Mar 2026 05:41:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by CH1PEPF0000A347.mail.protection.outlook.com (10.167.244.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.17 via Frontend Transport; Tue, 17 Mar 2026 05:41:32 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 17 Mar 2026 00:41:32 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 16 Mar 2026 22:43:27 -0700 Received: from [10.136.37.230] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 17 Mar 2026 00:41:26 -0500 Message-ID: Date: Tue, 17 Mar 2026 11:11:20 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v25 1/9] sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr() To: John Stultz CC: LKML , Peter Zijlstra , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , "Daniel Lezcano" , Suleiman Souhlal , kuyo chang , hupu , References: <20260313023022.2902479-1-jstultz@google.com> <20260313023022.2902479-2-jstultz@google.com> <20ea3670-c30a-433b-a07f-c4ff98ae2379@amd.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000A347:EE_|CY8PR12MB8066:EE_ X-MS-Office365-Filtering-Correlation-Id: f06a99f5-a7ba-4b16-4b6d-08de83e7d885 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|7416014|36860700016|376014|1800799024|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: KbOmer07+h7JHpiEa0U2j58bNlioJA00yOvK4uN6S1/mYJGTf8Y78oQ5eLufoOLUzsYYhsFFQyw3z/gZW93fByuEp7wsskTPu31wb6zJTT75Qp3HpxQ1SPYfiFSM4+6agOnHVmDS3KX/+2rg2KfKTO5NBQfI527dyq8LdLX73XdGzx1S0J6PFc4LgK+D8LN7cAq6f4/2zGZKQEU4TlV5KOafVdeLNSKXNX1WlSjVOoEVViJVqfjuCWKVjRT/1iFYsXSUV2gai0+Rn9RXrHQXkywV9cQ8EXEgg5p+6AHjqKM105ghGO8GWzdYHIthOzbqPdQFsTxPT+Rb0OqtoccgW2G/RpVSow2jktToZWAWDN6KLuzjMpbMKyXanlhxx7bBn+gCOCePOPcFIv8svqDFx3yL+j5v+J8p3aA111wlmaDkmZMoJmxkFJfQM8oxcGwCRt8TBS4N0M6nVj9xWz2szihJhy9zdIJpq5MWJeBlUlavs8PDGzgTPXFkY6lGEfKFTzxAKKwEyqvoLrltCxsKxIzysphHp8jE2S4qWJtq5uLWoldIk8l6tiSEp/FuZeDk3f3d6kac1a0wJ7igjFw1ir/X+0gA1gaU1zKip+aOuPH5G87enatpx0UQtqjKBm4+pBCjqBkT3hU8ChCrCBqzxcRIfWo/dfMdPrzjs8rAwIOntDlDmhMuebcYdEOfdtRN6h4pSYqYuqJsXZEW+5Om3jOhI/h2ZaCtOBnyOB9Oq2NGV9tvzdBEV1H4HB7Uc8X8vxjHynDbLJskgtUXLi1eXQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(7416014)(36860700016)(376014)(1800799024)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 6UHu8RhL44m9sgw/JdL3o8f10rwVw4GWnazf+epa3/0C/nLD8riXOmarkgGA/X917qoUn47n/jGcpZ9xLpZegEyooGLVOn3upC7HXJOsr8xQAQfA2ozT8fJ/B/Qv19auHovQPvaTbAfvvrXX6YTaAhR/CzH+QMGIrUVjrdfflPUdprbg6BDf6t41I25PNbAfG/Z5vDC8m7Kkaq91HCgNIpRrdap6pQxQYTRAmz4/ngqXNw1dQI0jzoZg7otrrsqdLMaLcQkyCnU1tsqtwyqjE+w2iV6Xe7/NduuS4LC8IqMhQKV0x0niGjpgM4Yg2Y/MrFOhFBPe22kqtMamB5Azc9QY4jpp+COpvbg/ejEgWs45+mTwtPbxjfsQXHpBSHU6mGXF5uFkz6nUeVYinY5v660Nd0m9uiUWRl6xWho8aGnjom0zzK+vyI1b6fFg4ENo X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2026 05:41:32.6139 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f06a99f5-a7ba-4b16-4b6d-08de83e7d885 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000A347.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8066 Hello John, On 3/17/2026 10:19 AM, John Stultz wrote: > On Sun, Mar 15, 2026 at 9:27 AM K Prateek Nayak wrote: >> >> Back to my concern with the queuing of the balance_callback, and the >> deadline and RT folks can keep me honest here, consider the following: >> >> CPU0 >> ==== >> >> ======> Task A (prio: 80) >> ... >> >> mutex_lock(Mutex0) >> ... /* Executing critical section. */ >> >> =====> Interrupt: Wakes up Task B (prio: 50); B->blocked_on = Mutex0; >> resched_curr() >> <===== Interrupt return >> preempt_schedule_irq() >> schedule() >> put_prev_set_next_Task(A, B) >> rq->donor = B >> if (task_is_blocked(B) >> next = find_proxy_task() /* Return Task A */ >> rq->curr = A >> queue_balance_callback() >> do_balance_callbacks() >> /* Finds A as task_on_cpu(); Does nothing. */ >> >> ... /* returns from schedule */ >> ... /* continues with critical section */ >> >> mutex_unlock(Mutex0) >> mutex_handoff(B /* Task B */) >> preempt_disable() >> try_to_wake_up() >> resched_curr() >> preempt_enable() >> preempt_schedule() >> proxy_force_return() >> /* Returns to same CPU */ >> >> /* >> * put_prev_set_next_task() is skipped since >> * rq->donor context is same. no balance >> * callbacks are queued. Task A still on the >> * push list. >> */ >> rq->donor = B >> rq->curr = B >> =======> sched_out: Task A >> >> !!! No balance callback; Task A still on push list. !!! >> >> <======= sched_in: Task B > > Hrm. I'm feeling like I'm a little lost here, specifically after > proxy_force_return(), since it doesn't exist yet at this point in the > patch series. Yeah I had to look a little bit ahead to poke holes here. Sorry about that! > But assuming we're at the "Handle blocked-waiter > migration" point in the series, I'd think it would be something like: > > rq->donor= B > rq->curr = A > << task A >> > mutex_unlock(Mutex0) > mutex_handoff(B /* Task B */) > preempt_disable() > try_to_wake_up() > resched_curr() > preempt_enable() > preempt_schedule() > __schedule() > find_proxy_task() > proxy_force_return() > return NULL > pick_again: > next = pick_next_task() > __pick_next_task() /* Returns B */ > rq->donor =B > rq->curr = B > context_switch() > <> > finish_task_switch() > finish_lock_switch() > __balance_callbacks() > > Your point "put_prev_set_next_task() is skipped since rq->donor > context is same" wasn't initially obvious to me, as the fair scheduler > does have a (p == prev) check, but it doesn't enqueue balance > callbacks. And for RT/DL/SCX we should be using the pick_task() > method, which calls put_prev_set_next_task() in __pick_next_task(). > But indeed, *inside* of put_prev_set_next_task() we return early if > (next == prev). > > So I see your concern and agree. > >> So what I'm getting to is, if we find that rq->donor has not changed >> with sched_proxy_exec() but rq->curr has changed during schedule(), we >> should forcefully do a: >> >> prev->sched_class->put_prev_task(rq, rq->donor, rq->donor /* or rq->idle / NULL ? */); >> next->sched_class->set_next_task(rq, rq->donor, true /* to queue balance callback. */); >> >> That way, when we do set_nex_task(), we see if we potentially have >> tasks in the push list and queue a balance callback since the >> task_on_cpu() condition may no longer apply to the tasks left behind >> on the list. >> >> Thoughts? > > Yeah. I wonder if we can express this inside of > put_prev_set_next_task(). Reworking the shortcut to maybe: > if (next == prev && next != rq->curr) > > I probably need to think on this tomorrow, as I suspect the above has > some holes, but it seems like it would catch the cases that would > matter Also this needs to be done after find_proxy_task() since "donor->blocked_on" needs to be cleared to queue callbacks else we'll bail out on task_is_blocked() check in set_next_task.*() with PROXY_WAKING when it is done as a part of pick_next_task(). > (maybe the issue is it catches too much - we'd probably also > trip it if we A boosted B, and then we hit schedule and again chose A > to boost B, which we probably could have skipped). Ack! Doing it when the execution context changes with donor context remaining the same would be the most optimal. > > I guess adding a new helper function to manually do the > put_prev/set_next could be added to the top level __schedule() logic > in the (prev != next) case, though we'll have to preserve the > prev_donor on the stack probably. That seems like the best option to me too. Also, deadline, RT, fair, and idle don't really care about the "next" argument of put_prev_task() and the only one that does care is put_prev_task_scx() to call switch_class() callback so putting it as either NULL or "rq->donor" should be safe. -- Thanks and Regards, Prateek