From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azon11011065.outbound.protection.outlook.com [52.101.57.65]) (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 6272439DBD8 for ; Wed, 25 Mar 2026 10:52:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.57.65 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774435955; cv=fail; b=lAGBWBHguDh5FWphV8EmwXYGGROix0g2ZT3kgiTkm8m1HWoi7+s43sIBhNQWCiHF/cfBIZ3m/IFdAXoBYkoiTki3QcV9A9ziLzfdibtaDzk6H53nSwp4b3FurVDX5DBkCJ9TEmJ/NZXIcZ7MpDRVRFRTTH2+RsnRygy9Anu7/ic= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774435955; c=relaxed/simple; bh=ejmTsUT9yk99Mufq7Akpc1HQYksICSnjzV21rRh2Css=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=ju9FXii+D+6zY3JZUiZ0CYkGxlX/3ZULvltsk4qV2XyftnGYs9O7+8AWhzUNNaD8VfS45W2X9gkD9LzsYwTeqhT+vHYVt1q3XS7vKAL4ZX77M0ih4g8hz3venGicfJb+tJSHls9uNDA2AasXq6kZQp+daPejw/iB0pZg/A2adIE= 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=dz9uVRdC; arc=fail smtp.client-ip=52.101.57.65 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="dz9uVRdC" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Utr8NVBRtIYk1MDhBaI92LipjvKQJ7r1w6SoLShtqqxBSsxCbERRj3Rd0r41oUUIx3OKonNuoGa/XboZ25lrC7bRpgXl3Mc8ZUr8n6G8gulH5EKj69nq7ZiFNWYiqLibGQFnw7+CXKvKdcl78yO+b0a0cE4v4WsZiKyMcYUR2STVZZCaBTMkm1E3vpvXUR1jiIhNGb+a0tokoeYMxIESbwj5Rsli3YevT6de+REc/Pno/XNoFAqdBF8/PfZdeIJHYK+Ofhe72yJqR2AadSeYDgZxXN/6S4+t2j7q42zoH2AXgohQQsTVl5rCmwO0S3Crjka4Hcrpt8Zu6oGuTf/Olg== 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=+WmY22Ve8Mj5aqqHswaxIBo08a+6XAcrsiM9viNT2Ho=; b=mhIJTT/8TdRfVsnr9XEcPHgSKD19U61jj8HX4rk0I09av3nJsOZwvBWLB+S+gb09jljhogL2eLu8MuSx682Agan1+AGeWUPEdG7MaM2jJ+EjPJpy0x+rffVwbHSH1icxUU7QGhwxwPWOe3+a6BYXk0/7ghQfKiSZv9WgxhFos2LJ6xk0QGTFBiT014Y89QW+Dhu0rZcmumwwD1HXdgCh+VNnzFnqjkl8tqTn2c1wLx00MHRY2Z+BpINCQf32cZnaqKiiUHpxXnAxiEn2xrngX42YCmj5hKAoEeQJo9tuN2g8/GTGUKw4/M1RasvNJBaEMwb16k6cTLMVcl0AkfaXVA== 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=+WmY22Ve8Mj5aqqHswaxIBo08a+6XAcrsiM9viNT2Ho=; b=dz9uVRdCCARIyv4DPDr15ZiNzq+0IG0fDXxFgpPtZ1co7C5z6p9n4eMUvAv7rh0AZLph0KcUHRw0pvUV3W3xXTJ0XpPB4RngwfONsqyP3+uKypRv9eZhM5MGs3+aVUJ8pweEZEEC5Ofrn7yufHlshd9WT8A2VGqtY68/VLNoUhI= Received: from DS7PR03CA0010.namprd03.prod.outlook.com (2603:10b6:5:3b8::15) by BL4PR12MB9478.namprd12.prod.outlook.com (2603:10b6:208:58e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.9; Wed, 25 Mar 2026 10:52:27 +0000 Received: from DS2PEPF000061C1.namprd02.prod.outlook.com (2603:10b6:5:3b8:cafe::3f) by DS7PR03CA0010.outlook.office365.com (2603:10b6:5:3b8::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9723.31 via Frontend Transport; Wed, 25 Mar 2026 10:52: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=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by DS2PEPF000061C1.mail.protection.outlook.com (10.167.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.21 via Frontend Transport; Wed, 25 Mar 2026 10:52:27 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Wed, 25 Mar 2026 05:52:26 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 25 Mar 2026 05:52:26 -0500 Received: from [10.136.39.136] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 25 Mar 2026 05:52:20 -0500 Message-ID: <36e96f87-a682-436e-aefc-13e2e5810019@amd.com> Date: Wed, 25 Mar 2026 16:22:14 +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 v26 00/10] Simple Donor Migration for Proxy Execution To: John Stultz , LKML CC: Joel Fernandes , Qais Yousef , Ingo Molnar , Peter Zijlstra , "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: <20260324191337.1841376-1-jstultz@google.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260324191337.1841376-1-jstultz@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: kprateek.nayak@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF000061C1:EE_|BL4PR12MB9478:EE_ X-MS-Office365-Filtering-Correlation-Id: 4abf5d76-4075-4e64-adfe-08de8a5c9adf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700016|376014|7416014|56012099003|13003099007|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: Yj4bB0rC0Mnezn6Zc3B0GzHQ/pSw1Nda64lE8USre+KE9Q4n5EHPLASRrsSZxecTOvol+qI0MQesb031vdlxUs5eV82DlL5CZNuL/tjGvBrhpRGMi1TR8duQKl6K396hHt6Agor0OcYn+KYpsHDudGVr5OZXWddrmz/P/po4++1bxSxgh/p3mHHCgUyXxQz8dOGBZAO1ODiWgV4Ijc7SLvz5G5X20tqYEoBTwmZkPTtzpdvjmtQlOrGhGobFrSc+BB1sy8LNLem7kZb7boddxLmtTZz7xGAyiO3M4uHMBeFdyPpJ5IwuI9Qp/fnk7sHD7XA1o1XrBI93ZkdJhDmhs+ErHG8zy2jLWae4N28wiSQVPqiI6g1EGc+v2aak5OhFBZEfmx7Iten3p5ugGLWuxsTxYsz/sbyNpeQE9ZJjaWq/Pp5561RmZEQJkcz0wgMwnvfjGjlcXpPYdErsKMvCxDtxwNEyhwvuyVoiSNDX0xqVwzS81BH5scaY451Aeg4YRJTlR2ZRrgdhIrF1TQCJZngQC+iRe1HDMeFkShEnNatjXvRTikzRKC3nbHt1lbIEqHTWnZjmAxTtGKzyPJIdiKtvXqEuxAWV3ZcnTgEW+bZrETRQHL0fWnbaizmmF99s9OmY6uKdYUu6jHCMHziYYaJnU01MZXNJskMabhX0qMDztloe/S2Qmtg3NuoV0QJjbWvogdrnm9iNUAlrLpTjsYxS8cc54HVMVDo290wigjs= 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)(1800799024)(36860700016)(376014)(7416014)(56012099003)(13003099007)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: FtlI444pCsQKMwAx13om0rsarn0tYaa4EbfO53LK8MpTO/MQ8cMobcwblp3JJjfoVi7sDD0e6XnufYtJeUGR+yeljpP2tFCxi0T/up6AEas6SVRSbX3pbiugeFRDYbQGeWFKhLkOiiiw8xxnlLF1Z7DHaqtbcQp99aVckoaRDbcHHpq/KvwQm+IPTJsJ/km4svg9jm8iT+hGWlXAVnmGO64fixAaWtreJX8XLcZS0ZKm0nQKS901Wehzv3ISxlWP8bCFgZ4RG/uiEwM5MnuEW0OUZJe7QuFgL+pXkK7ExlUT3yso3iJhI6lsXN3xDKWWLyrVic/7uZ7XjxzWTbsuBx3hiF1RTupT1aTkVTi+P7o4E/Gk88aUFSmPtK/zlCeYecVbxOnHeF5X8TyIN+4459F9UHNkHFQPeVm3pO7GpXH7TBXYqLXADjuCoTYTYzeP X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2026 10:52:27.2725 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4abf5d76-4075-4e64-adfe-08de8a5c9adf 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: DS2PEPF000061C1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9478 Hello John, On 3/25/2026 12:43 AM, John Stultz wrote: > I really want to share my appreciation for feedback provided by > Peter, K Prateek and Juri on the last revision! And we really appreciate you working on this! (Cannot state this enough) > There’s also been some further improvements In the full Proxy > Execution series: > * Tweaks to proxy_needs_return() suggested by K Prateek To answer your question on v25, I finally seem to have ttwu_state_match() happy with the pieces in: https://github.com/kudureranganath/linux/commits/kudure/sched/proxy/ttwu_state_match/ The base rationale is still the same from https://lore.kernel.org/lkml/eccf9bb5-8455-48e5-aa35-4878c25f6822@amd.com/ tl;dr Use rq_lock() to serialize clearing of "p->blocked_on". All the other transition change "p->blocked_on" non-NULL values. Exploit this to use ttwu_state_match() + ttwu_runnable() in our favor when waking up blocked donors and handling their return migration. These are the commits of interest on the tree with a brief explanation: I added back proxy_reset_donor() for the sake of testing now that a bunch of other bits are addressed in v26. I've mostly been testing at the below commit (this time with LOCKDEP enabled): 82a29c2ecd4b sched/core: Reset the donor to current task when donor is woken ... 5dc4507b1f04 [ANNOTATION] === proxy donor/blocked-waiter migration before this point === Above range which has you as the author has not been touched - same as what you have on your proxy-exec-v26-7.0-rc5 branch. I did not tackle sleeping owner bits yet because there are too many locks, lists, synchronization nuances that I still need to wrap my head around. That said ... The below is making ttwu_state_match() sufficient enough to handle the return migration which allows for using wake_up_process(). The patches are small and the major ones should have enough rationale in the comments and the commit message to justify the changes. 0b3810f43c66 sched/core: Simplify proxy_force_return() 609c41b77eaf sched/core: Remove proxy_task_runnable_but_waking() 157721338332 sched/core: Prepare proxy_deactivate() to comply with ttwu state machinery abefa0729920 sched/core: Allow callers of try_to_block_task() to handle "blocked_on" relation Only change to below was conflict resolution as a result of some re-arrangement. 787b078b588f sched: Handle blocked-waiter migration (and return migration) These are few changes to proxy_needs_return() exploiting the idea of "p->blocked_on" being only cleared under rq_lock: 84a2b581dfe8 sched/core: Remove "p->wake_cpu" constraint in proxy_needs_return() c52d51d67452 sched/core: Handle "blocked_on" clearing for wakeups in ttwu_runnable() I just moved this further because I think it is an important bit to handle the return migration vs wakeup of blocked donor. This too has only been modified to resolve conflicts and nothing more. 9db85fb35c22 sched: Have try_to_wake_up() handle return-migration for PROXY_WAKING case These are two small trivial fixes - one that already exists in your tree and is required for using proxy_resched_idle() from proxy_needs_return() and the other to clear "p->blocked_on" when a wakeup races with __schedule(): 0d6a01bb19db sched/core: Clear "blocked_on" relation if schedule races with wakeup fd60c48f7b71 sched: Avoid donor->sched_class->yield_task() null traversal Everything before this is same as what is in your tree. The bottom ones have the most information and the commit messages get brief as we move to top but I believe there is enough context in comments + commit log to justify these changes. Some may actually have too much context but I've dumped my head out. I'll freeze this branch and use a WIP like yours if and when I manage to crash and burn these bits. I know you are already oversubscribed so please take a look on a best effort basis. I can also resend this as a separate series once v26 lands if there is enough interest around. Sorry for the dump and thank you again for patiently working on this. Much appreciated _/\_ -- Thanks and Regards, Prateek