From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azon11010014.outbound.protection.outlook.com [52.101.201.14]) (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 3CE66217F33 for ; Mon, 13 Jul 2026 04:22:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.201.14 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783916552; cv=fail; b=WDibxLH1HHoay8HVX3cqpFIdjkeputulTdvGdyVqgapbKRnf4OZM/eDxBbO1FGpSqTvvk/8XRw3a/+wzHH+cyekKQ/DQQt2mAMv9SmKvzFhML6Ghpn5TigDD71mLECe3rbj24BDHN+nJ6/QKugAXmAwFTSw2yEpdOScavW6Hed8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783916552; c=relaxed/simple; bh=a7yk3f4mv9gg7Y0QavUbXD8057QU0dvIhqTiNRl/KKU=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=VMEGFRWr44ad7qn6dW1foaf2dZVbV+z1pdvdDCXPT7bhx43P0+Rj/LpMOrRqXt9TBojC56/LbAPAEGDi8DG5KtfXMdngFmbdpzwPbeIWHAErSNyflAoNBeZlX4wpV6ZEjU7skJP+71XfNwkvH8GWQwV2vreGgLr7eEZmIcgG6hQ= 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=T1ZtRmlO; arc=fail smtp.client-ip=52.101.201.14 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="T1ZtRmlO" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SF2a6gcJpdR+5dU7ki2CEVHnuLHZlr9V1LCSXnU+T7OcFsSG6vBrqV9Oa9WPqutjPv5T53MfMlpAkeg6pOolYOoKP9hFz9kqpgkTIhBIMGWFe27MiYmYazmYJWnFcH+xqoygsRK7SN3xYUSyENYhn1ZBXItGmk7pDAHl2H/8Kgw6RhWdp0d2c3uupT5yonLTgBMEALdfPia2cSHZ2v5NllOmB+IqSVl9uvfjqdeszMbAmf9j+r+QrZMZF+aTbAm4v03yYK+2HWnDFnTQ0RH/LUGIFZ3WAqgg7coUlkK+vccLP9eTygzy/j0uccEw9v0Yo+uBC8l48DE+Ewj6/vVo0w== 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=sfOjaPqxNGSGvdHdP0R69U19NdIrepPTl75TaCutAHY=; b=dLxlGoPqlK+gI8J7OWiTctIpU7WyL0DDGIaDn/xokitUbBcZQnOqpWXEJ8Mn0E3PUNjn2iyj5uFqKCRYs22uRJU1KJixTvE9da61uKFIQNEijUgn93ntbeyRCubZ+ANkgf8YxR3ZB8hK+ITBm1tg4zVSMvMvL8EqzzeKks2MnmK9qDXuwWh3TOrr33A7q47O2osF1TRQp/RMcm9zcvVq45NUgrFitA/sxTghv0nNALodmI2lAK02ZZ68b8eZKctGUfrpicNd1UyskmsmfZV7GgBCCQwnyEE6M+5Woy3ylCw3ao14ikErd45x3XMlOJzp29wRcmRi/b/GQDCE0wU2+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=zohomail.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=sfOjaPqxNGSGvdHdP0R69U19NdIrepPTl75TaCutAHY=; b=T1ZtRmlOm7NMXYLPm4zKEGefdHtdjSHCa93kpjqmaiULONYFGWAEK9bvPoWrtiDxasdvlC9mqENZLDcLzk+crF+WUVZ9RYi1/nDuQE70CCtPuP2ci9oTEqR+Pn3+z79INFeHEup6mPikU8dQ7/qdkgGuo0WSHkZZkpCEDrdafS4= Received: from SA9PR13CA0038.namprd13.prod.outlook.com (2603:10b6:806:22::13) by MW4PR12MB7143.namprd12.prod.outlook.com (2603:10b6:303:222::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.202.18; Mon, 13 Jul 2026 04:22:20 +0000 Received: from SA2PEPF000015C7.namprd03.prod.outlook.com (2603:10b6:806:22:cafe::4d) by SA9PR13CA0038.outlook.office365.com (2603:10b6:806:22::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Mon, 13 Jul 2026 04:22:20 +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=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF000015C7.mail.protection.outlook.com (10.167.241.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Mon, 13 Jul 2026 04:22:20 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Sun, 12 Jul 2026 23:22:19 -0500 Received: from [10.136.35.249] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Sun, 12 Jul 2026 23:22:14 -0500 Message-ID: <30ac52e7-3058-42f4-8f20-ff466716e9a5@amd.com> Date: Mon, 13 Jul 2026 09:52:13 +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 RFC] sched/proxy: Defer donor commit until after proxy resolution To: Xukai Wang , John Stultz , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider CC: References: <20260707-sched-proxy-v1-0-5928bf6dedf0@zohomail.com> <20260707-sched-proxy-v1-1-5928bf6dedf0@zohomail.com> <47c5e555-92ce-4ab1-8adf-c10639753b49@zohomail.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <47c5e555-92ce-4ab1-8adf-c10639753b49@zohomail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF000015C7:EE_|MW4PR12MB7143:EE_ X-MS-Office365-Filtering-Correlation-Id: 48dcf3a2-6572-42f4-4c80-08dee096548c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|82310400026|7416014|36860700016|1800799024|921020|18002099003|22082099003|6133799003|11063799006|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: 5wawRzQVJ2Jd/THtBOlFEFvJ6HXIm75WwNXe/3S4Hov6sKqsB6D9uYirmDVI2V1Zpoy4OhqYf3fS4XKB756CBxgBA8fk6ws+cPxFnfC3cES/uKR1WQHs299b/HOnAQ0MmN23B9qTHoYSywdAsIJtsSkdwXHJCJYaNRbNTbYz84dCo0rKoMXhK4mKmbrELAO5EYFyPS2m4P3z7SJdgBpzXca4fNsIzrPtPpegLKSaKsEOWUHM2OYKF/hffPut6li0PUQkyRumV8EoR5pAi1BbrNsTdktRl23vPv+qLAL5llHjvxKu9ry98bb/LIsK4thDXcdjBSezXkG4R22nae85Kzi2mhlt0BlUR/3SoWzm4sIDI3okjsnlmdpxQyYaNItmrntfSan5yf36Px9r4uitI5SMsVFrgDLXvWgaIE/SbaeJv319eDruL3oeU9iN+zZgWaTFA8fBTg5JlP8+v/PPcCFXOOh/vCoC8HQJNa1L+Z5nRRvNaHVAQNMs0zqwFyqGyVwKbqxWUcy3B8D1C+Z03VIW/dkXPoyKKFqyeBP8Z4xRamTdni9HVMBBFgBvH4Ojw+iEdUkOEzZOeMEpahL2vhxJI/MegKjrV0ZChiYuJrc+ZFbun2hZUoQZ1HI4voPAw770tg8PS7nnv+hsaesZgYdwYw0Fdm8gc3L6fNPaBBGfZpKdqGrdccBH3SUZ6/H1N9n2zp1t18rN7a1fcdg/ivvm69PWAJ/whIlMV+lV0SMas4T3kyfmAfUunt+Wa5WN X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(82310400026)(7416014)(36860700016)(1800799024)(921020)(18002099003)(22082099003)(6133799003)(11063799006)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Xn1GluYzrmk18INXnVBnF27laL0O4K6T61H/ZXVM0o0sbUow/V9GbI2bfAIYSnZkKwZmV7/FCqhCal0pSm+NiuR7atzpaLF49GiXd9g2gglVIlVWMEG/fJW/T9gaxlabOP1haAsnAUt6+YBbjN0hPtzccxCo24sZUiB/dBGof4I0P98rClzTRfxetldqNSpuqnkL9nYD22T02cA0mxwbkCbc9Evb2K6jghHTwAoIXykqwevy2kpHOmj9n8Dq0+tHyPZf39RHpvIkLbRaOf0IdT0Yfepz9oby5GzhXrgjT46ELKeEXCfYUfTmrPxRb9wqeYfMDskbtDCRywBNRpi+GhSZRrtrdllm3m+7+lj4PPdssHR2PIOsqVgohOX6X8f7LVU9cGeWRNe8twEvU4eDwuuJ70HSEr+GapSWiIlmBMJjJQniJ9BvXseSRPLj7CQ0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2026 04:22:20.0763 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 48dcf3a2-6572-42f4-4c80-08dee096548c 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=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF000015C7.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7143 (+ John) Hello Xukai, On 7/10/2026 8:44 PM, Xukai Wang wrote: >> On 7/7/2026 9:16 PM, Xukai Wang wrote: >>> pick_next_task() currently commits the selected task into the scheduling >>> class state before proxy execution has resolved whether that task should >>> really become the committed donor. >>> >>> With proxy execution enabled, the task returned by pick_next_task() may >>> be blocked. __schedule() then calls find_proxy_task() to resolve the >>> proxy chain. If find_proxy_task() returns NULL, __schedule() retries >>> through pick_again, but the picked donor has already gone through >>> put_prev_set_next_task(). In that case the class current state was >>> speculatively switched to a donor which is not the final scheduling >>> decision. >> As long as rq_lock is held, the pick will always select the same >> donor since there cannot be a wakeup / migration until the rq_lock >> is released. >> >> If there is a change in the proxy state, and the lock needs to be >> dropped, we do a proxy_resched_idle() and transiently switch to the >> idle task's accounting context. >> >> If we don't need to drop the rq_lock, we just retry the pick after >> dropping the blocked_lock and the pick will converge to the same >> donor unless ->balance() manages to pull something. >> >> Very often, it is the same donor task pick converges on. I don't >> see how this transient state is a big enough problem to see any >> noticeable overhead. > > I agree that, if the rq state does not materially change while rq_lock is > held, the retry can converge back to the same donor. I did not intend to > make a performance claim with the RFC. The counters were meant to > characterize what happens in the proxy path after a blocked donor has > already been committed. I've added John on this thread in case he knows of any dependency in the find_proxy_task() bits that rely on rq->donor being updated with the recent pick (I, personally am not aware of any but there might be some dependency that eventually gets added with the full proxy series that I haven't yet considered). > > I added some temporary instrumentation on the baseline kernel to check the > retry behavior after find_proxy_task() returns NULL. The test was run on > top of tip/sched/core at commit 19b7bdc3a1550ab2550427c33395bec7caeaf72d > with only temporary debug instrumentation added. > > The test uses a small misc driver which repeatedly takes a kernel struct > mutex and busy-waits while holding it. A userspace stress program creates > one low-priority holder and multiple higher-priority waiters pinned to > selected CPUs. The specific run below used: > holder CPU: 1 > > waiter CPU > > base: 0 > > waiter CPU span: 4 > > waiters: 8 > > duration: 60s > > holder hold time: 3000 us > > waiter hold time: 1 us > > waiter policy: SCHED_RR prio 50 > > The temporary counters mean: > spec_commit_blocked:pick_next_task() selected a blocked donor, and in > the baseline code that donor had already gone through > put_prev_set_next_task() before proxy-chain resolution. > > spec_commit_then_null:the blocked donor had already been committed, but > find_proxy_task() returned NULL and __schedule() retried. > > spec_commit_then_idle:the blocked donor had already been committed, but > find_proxy_task() returned rq->idle. > > spec_commit_then_success:the blocked donor had already been committed, > and find_proxy_task() successfully found a task to run. > > null_retry_same_donor: > after find_proxy_task() returned NULL, the next pick selected the same > donor again. > > null_retry_diff_donor: > after find_proxy_task() returned NULL, the next pick selected a > different non-idle donor. > > null_retry_to_idle: > after find_proxy_task() returned NULL, the next pick selected idle. > > In that run, I got: > find_call 5407 > find_success 523 > find_idle 1660 > find_null 3224 > > spec_commit_blocked 5407 > spec_commit_then_null 3224 > spec_commit_then_idle 1660 > spec_commit_then_success 523 > > null_deactivate_no_mutex 6 > null_deactivate_no_owner 125 > null_deactivate_owner_not_runnable 962 > null_migrate 2131 I think the chain-migration bits can bring down some of these null_migrate calls substantially. > > null_retry_same_donor 0 > null_retry_diff_donor 2258 > null_retry_to_idle 966 Seems like you mostly have one task that keeps getting migrated to the owner's CPU. > > So in this workload, the selected blocked donor had already been committed > before proxy-chain resolution, but most resolutions ended in NULL or idle. > For the NULL cases, the retry did not pick the same donor again. Most of > those NULL cases came from deactivate/migrate paths, so this appears to be > the kind of case where proxy state changes before the retry. > >>> Make pick_next_task() return only the selected candidate task. Move the >>> put_prev_set_next_task() call into __schedule(), next to rq_set_donor(), >>> so the class commit happens at the schedule level. >>> >>> For proxy execution, keep the picked donor separate from the actual task >>> to run: >>> >>> donor = task selected by pick_next_task() >>> next = task returned by find_proxy_task(), possibly the mutex owner >>> >>> Only commit the donor after proxy-chain resolution succeeds: >>> >>> put_prev_set_next_task(rq, prev_donor, donor); >>> rq_set_donor(rq, donor); >>> >>> If find_proxy_task() returns NULL, the candidate donor has not been >>> committed and __schedule() can retry without first undoing a speculative >>> set_next() on that donor. >>> >>> A proxy candidate is not necessarily the committed rq->donor anymore. >>> Update proxy_deactivate() accordingly. If the task being blocked is >>> still the committed donor, proxy_resched_idle() is needed to drop >>> rq/class current references before block_task() clears ->on_rq. If >>> it is only an uncommitted proxy candidate, it is still queued and can >>> be blocked directly. >>> >>> proxy_migrate_task() still switches the rq to idle before dropping the >>> rq lock. Migrating a task found in the proxy chain abandons the current >>> proxy pick attempt, and switching the committed donor to idle leaves >>> rq->donor and the class current state in a defined state while the chain >>> is modified and the task is attached elsewhere. >>> >>> This keeps the proxy donor accounting semantics intact: the scheduling >>> class state is committed to the donor, while the actual context switch >>> may still be to the proxy owner returned by find_proxy_task(). >>> >>> Signed-off-by: Xukai Wang >>> --- >>> kernel/sched/core.c | 70 ++++++++++++++++++++++++++++++----------------------- >>> 1 file changed, 40 insertions(+), 30 deletions(-) >>> > ... >>> >>> @@ -7147,11 +7153,11 @@ static void __sched notrace __schedule(int sched_mode) >>> rq->next_class = next->sched_class; >>> if (sched_proxy_exec()) { >>> struct task_struct *prev_donor = rq->donor; >>> + struct task_struct *donor = next; >>> >>> - rq_set_donor(rq, next); >>> - next->blocked_donor = NULL; >>> - if (unlikely(next->is_blocked)) { >>> - next = find_proxy_task(rq, next, &rf); >>> + donor->blocked_donor = NULL; >>> + if (unlikely(donor->is_blocked)) { >>> + next = find_proxy_task(rq, donor, &rf); >>> if (!next) { >>> zap_balance_callbacks(rq); >> You don't need to zap any balance callbacks if you don't do >> a put_prev_set_next_task(). It should always be empty here. >> >>> goto pick_again; >>> @@ -7161,8 +7167,11 @@ static void __sched notrace __schedule(int sched_mode) >>> goto keep_resched; >>> } >>> } >>> - if (rq->donor == prev_donor && prev != next) { >>> - struct task_struct *donor = rq->donor; >>> + >>> + put_prev_set_next_task(rq, prev_donor, donor); >>> + rq_set_donor(rq, donor); >> Since the next condition only cares for donor == prev_donor, I >> think you can do this after the next block and unify the >> !sched_proxy_exec() case too like: >> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index f13f53bd6d9d7..c6e37005a73c4 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -7171,9 +7171,6 @@ static void __sched notrace __schedule(int sched_mode) >> } >> } >> >> - put_prev_set_next_task(rq, prev_donor, donor); >> - rq_set_donor(rq, donor); >> - >> if (donor == prev_donor && prev != next) { >> /* >> * When transitioning like: >> @@ -7190,10 +7187,9 @@ static void __sched notrace __schedule(int sched_mode) >> donor->sched_class->put_prev_task(rq, donor, donor); >> donor->sched_class->set_next_task(rq, donor, true); >> } >> - } else { >> - put_prev_set_next_task(rq, rq->donor, next); >> - rq_set_donor(rq, next); >> } >> + put_prev_set_next_task(rq, rq->donor, next); >> + rq_set_donor(rq, next); >> >> picked: >> clear_tsk_need_resched(prev); >> --- >> > Based on your comments, I am thinking of restructuring the patch like this. > > First, move the final put_prev_set_next_task()/rq_set_donor() out of the > proxy/non-proxy branches. I think the common commit target still needs to > be the donor rather than next, because after find_proxy_task(), next may be > the proxy owner that will actually run, while donor is still the selected > scheduling donor/accounting context: You are right! I had not booted into a kernel with my suggested changes to have realized that mistake :-) > __schuedle() > > struct task_struct *donor; > ... > > next = pick_next_task(rq, &rf); > rq->next_class = next->sched_class; > donor = next; > if (sched_proxy_exec()) { > struct task_struct *prev_donor = rq->donor; > > donor->blocked_donor = NULL; > if (unlikely(donor->is_blocked)) { > next = find_proxy_task(rq, donor, &rf); > if (!next) > goto pick_again; > if (next == rq->idle) > goto keep_resched; > } > > if (donor == prev_donor && prev != next) { > donor->sched_class->put_prev_task(rq, donor, donor); > donor->sched_class->set_next_task(rq, donor, true); > } > } > put_prev_set_next_task(rq, rq->donor, donor); > rq_set_donor(rq, donor); > > Second, for zap_balance_callbacks(), I noticed that some NULL/idle paths > can still go through proxy_resched_idle(), which performs the idle put/set > transition before returning. So instead of keeping zap_balance_callbacks() > at the outer !next / next == rq->idle sites, I am thinking of moving it > into proxy_resched_idle(), next to the idle commit itself: > static inline struct task_struct *proxy_resched_idle(struct rq *rq) > { > put_prev_set_next_task(rq, rq->donor, rq->idle); > rq->next_class = &idle_sched_class; > rq_set_donor(rq, rq->idle); > set_tsk_need_resched(rq->idle); > zap_balance_callbacks(rq); > return rq->idle; > } > > Then the outer NULL/idle paths no longer need to zap unconditionally. If no > put/set happened, there should be no callbacks to clear; if the path went > through proxy_resched_idle(), the callbacks are cleared at the place that > did the idle commit. > > There may be paths such as proxy_migrate_task() where proxy_resched_idle() > is followed later by proxy_release_rq_lock(), which also zaps callbacks > before dropping the rq lock. My current thinking is that this is still OK: > proxy_resched_idle() clears callbacks from the idle commit itself, while > proxy_release_rq_lock() remains the final cleanup point after later > dequeue/migration changes. But I would like to know if you would prefer a > different placement. > > Does this look like the right direction? Your suggestions look correct to me. Perhaps you can send a v2 including John and we can take a look. > > If useful, I can also share the temporary instrumentation and the exact > proxy_mutex_test setup used to reproduce the numbers above. I can further > look into whether this has a measurable performance effect, but I would > keep that separate from the correctness/commit-boundary question unless > you think it is necessary for this change. Just the patches should be fine. I can crunch the performance numbers from my side with schedstats and update on the threads. -- Thanks and Regards, Prateek