From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azon11010018.outbound.protection.outlook.com [52.101.56.18]) (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 969AB2222AA for ; Sat, 28 Mar 2026 04:53:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.56.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774673602; cv=fail; b=n8EJ9WkpoEwY6Z2cZAoPOWY1D6vtGLdUV7sq37i/tVr6v5Y0IcnR59/IWD6QO2x53Ew2oQxquR2IBGhyAfk1tBjViKlDBpii28/YOOeJzb3hUgO8j9uViUppHs3pOpriw1VkvYvlKeCnl0xIDrk8BoqEiKYw5QSajBX8dJDAzzs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774673602; c=relaxed/simple; bh=jJ//tUcveEoYb/9TJPyXKo1Bx4/5Ilh9j6FXukl8K6E=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=rIsmb7BaCThFdT59FltT3JqxxW+wH5AuVh126emnzot6WOuNDhbgRTIoxfECf5AxlVs+cSFbGjIgfglbCBjBm+QqHxgQMRq+PQ2t241LuSuSvW9YCBU9KjomXyJzx4MqmKmH5+yTq8iau3sSg83Yys6pVaK9N6L+IqNeP3/1YW8= 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=uUM00cIy; arc=fail smtp.client-ip=52.101.56.18 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="uUM00cIy" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v4oswW6Wt0wFmiv2lhljKAowochTQ3Ov8FQkQfm2T0LEFxZjxllVw+90RFSQGGLPqxqQwoUiVZGJXnxB1x5Ie5Ir8mYdQSpuc5YrFyy6YE+tuvKX8XXmaaTdyGBHOja9fzCxj9fsbDf3xGT8pixeWZ4Y4TvNJRGea5c2TkWvBBGP+7tm+JDjLM+Cz1QQycWGnyRlnnWLT4uhaFqtuouhtOimlENGHdtlNxoALbm6MumRCBWhs4WQYgGKAYbn9CcIHV9gP2XVN/lOcKKvcE8q8+YX+8lfSe6GjLuWOO5VPCVvJpOSdD9+RkspYaPnwq19U0kq9h2gznqNpBV19uTS7A== 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=bPm+MONIbD+ovjkNNZHbnY4LBoAASVVhbM4o+IgyDs8=; b=UvJ/Hu3ustUDngrP5kqtCaksrklelakJW+miofJuZdoS4jajyQKMVYII0uLFsjXyoFvWBQDWMNz1+TtdUpRGS8mn3aQoFp1iCZX1NqY3iobmSwQpkvPElkPo0CwNrqwE8VaQJXL55APtjCMKBS9mXH9iO/ZzHgGHx8RY1ZtZkneaRORlgwY66wfDVG83fa9vT4Qn1qV4fyA9GNiGVF4/78CJSgoZnLMuE4CT+YOwha5QqrxY1S24i9eHuXVsrIP/julpT5yRVHhhRuIz/Od0QMTywIrk8po9nWivTuT/DQAXuOsR2XUaUbePxj+qyGh2M5Banxu6m3t98ti5JqicXQ== 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=bPm+MONIbD+ovjkNNZHbnY4LBoAASVVhbM4o+IgyDs8=; b=uUM00cIyACvZyodNHuAN2D6KWmPxF89M581vk9G7mHKRluNYhflqY5vEduRurcP4FKf94jLIMBP8AJw/I+UakDeNujvGsGfoJs83jfGr292sX3X42Zkv3UKWHPHxE9wP57XegQ00ZJ/MpT6SHKWr9ozTiu+xMQSnhto9Mo1rp1M= Received: from SJ0PR13CA0056.namprd13.prod.outlook.com (2603:10b6:a03:2c2::31) by MN6PR12MB8491.namprd12.prod.outlook.com (2603:10b6:208:46f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.11; Sat, 28 Mar 2026 04:53:10 +0000 Received: from SJ1PEPF000023CD.namprd02.prod.outlook.com (2603:10b6:a03:2c2:cafe::fc) by SJ0PR13CA0056.outlook.office365.com (2603:10b6:a03:2c2::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9745.20 via Frontend Transport; Sat, 28 Mar 2026 04:53:10 +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 SJ1PEPF000023CD.mail.protection.outlook.com (10.167.244.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.21 via Frontend Transport; Sat, 28 Mar 2026 04:53:10 +0000 Received: from satlexmb10.amd.com (10.181.42.219) 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; Fri, 27 Mar 2026 23:53:09 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 27 Mar 2026 23:53:09 -0500 Received: from [172.31.184.125] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 27 Mar 2026 23:53:03 -0500 Message-ID: <926383b1-dd21-4632-8ef5-c0dafb7b429e@amd.com> Date: Sat, 28 Mar 2026 10:23:02 +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 CC: LKML , 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> <36e96f87-a682-436e-aefc-13e2e5810019@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: SJ1PEPF000023CD:EE_|MN6PR12MB8491:EE_ X-MS-Office365-Filtering-Correlation-Id: 6708a085-48db-485d-8ade-08de8c85e92b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|7416014|376014|82310400026|1800799024|13003099007|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: hnNckYhwB8mEvhL9/2Mzg337iHsTLMDVjIvmSamWmZ6JU8VuqFg9khon2Ce5xl0B76ynBncXPotmQJ5oMToSWzLluJGXyGYYctgdfDjcF+CZMsHP/h/4vh9bstDbMSzD8gsua4OuqtAHhig+uZfCUhdrNLe5JfZjHBQ5Y3/Mz1qNjI8XA26bS5SZsxPJNg/SnK5zeNKIWk6insM6lDtMficyWf/ippLYdm0rSIns1bkau0A1ejptk3iy2HyT/IskvYqJA9jC8Q5ABY4S2uxecFl22vtIp/U9+ah9B7SbY/dMYpg7ZmIc4eJaEwGeaM+Tollcpugf046q+N04z3+EtGZrhgdNSLANPWP25Ek93DisT1eSF19AjAP7QsXtON8PNgIs0lXXun/Wkwn2sNVLWDUwXXJvNXUKKxjDzX44BgOAXDSnqXLe1xxbqW+UdQHrNQldBwPDm170WTRhqx5Of7sB4dwKPDXoS0Qu46YpDTowpbrRRghuaHN2CJxHRqjqmq2rQo0OOi2nnDfuSVQqs6ITETlHjOJNmtNtQf60arMxomiGUAE2ndZVNRYz56rwf/ldwySuqXRJ/TwAcO7omyAbLB8zTP3JRF0XcRgzg+9apkg0NPRXSvOUgKKiJoQPsqQWZhpCxR8TlO4U23Ot6Ahgrtqs7vADNLkPMOUVT52RLuXcWa+kzR5TJSbu4KvJOIcyqpqYuPNcvlIIdncIJPd6JsZrdrzMe6BGdgRHpxA= 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)(36860700016)(7416014)(376014)(82310400026)(1800799024)(13003099007)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: NNMKJ7UOBDOK8WBU+ZNWi/fF29ufw/32X0VTQ2LHDbdXjcLW7S+Ni6DtTlUgUELi9nR7p2l4Qp+iyfF0S3vnvkaRXwL1WAx8X7smQnRWWbgz+UQR2J2a0dUwilxU+v1Ayf95+adullKTpMgzouOY52edZmxACwtdk47aLF4fHbSMZ90N13QTkDoF2sclVAnvHCYrdZuY+BnL3QnrhX3yhnllO4yRVcOglMMWuXBa7fDFSIPLz589+T6jwXT/GlenXYxezOxPfqqgd5e6raSb/ffO3JDeLUv5vd4wDj9Z2xni7xZxlo4z1BOzGwEd7Do/uo8bovrXUYyXaKOlLQKxplxZQeHsJsoiNQQRTmDWVsqI253aAMlhhsItuF9+jVc/Ec2l1ZxzLmG3nOGujRlNmTT7+jMTDKcfhlh+Z9gCtHgMlga9+rCyA1udPo3FDn/4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2026 04:53:10.2651 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6708a085-48db-485d-8ade-08de8c85e92b 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: SJ1PEPF000023CD.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8491 Hello John, On 3/28/2026 12:40 AM, John Stultz wrote: > On Wed, Mar 25, 2026 at 3:52 AM K Prateek Nayak wrote: >> On 3/25/2026 12:43 AM, John Stultz wrote: >>> 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/ > > So thank you so much for sharing this tree! It's definitely helpful > and better shows how to split up the larger proposal you had. > > I've been occupied chasing the null __pick_eevdf() return issue (which > I've now tripped without my proxy changes, so its an upstream thing > but I'd still like to bisect it down), Is the __pick_eevdf() returning NULL on tip:sched/core or is this on mainline? _Insert GTA San Andreas "Here we go again." meme here_ > along with other items, so I've > not yet been able to fully ingest your changes. I did run some testing > on them and didn't see any immediate issues (other then the null > __pick_eevdf() issue, which limits the testing time to ~4 hours), and > I even ran it along with the sleeping owner enqueuing change on top > which had been giving me grief in earlier attempts to integrate these > suggestions. So that's good! > > My initial/brief reactions looking through your the series: > > * sched/core: Clear "blocked_on" relation if schedule races with wakeup > > At first glance, this makes me feel nervous because clearing the > blocked_on value has long been a source of bugs in the development of > the proxy series, as the task might have been proxy-migrated to a cpu > where it can't run. That's why my mental rules tend towards doing the > clearing in a few places and setting PROXY_WAKING in most cases (so > we're sure to evaluate the task before letting it run). My earlier > logic of keeping blocked_on_state separate from blocked_on was trying > to make these rules as obvious as possible, and since consolidating > them I still get mentally muddied at times - ie, we probably don't > need to be clearing blocked_on in the mutex lock paths anymore, but > the symmetry is a little helpful to me. > > But the fact that you're clearing the state on prev here, and at that > point prev is current saves it, since current can obviously run on > this cpu. So probably just needs a comment to that effect. Ack! > > * sched/core: Handle "blocked_on" clearing for wakeups in ttwu_runnable() > > Mostly looks sane to me (though I still have some heistancy to > dropping the set_task_blocked_on_waking() bit) > > * sched/core: Remove "p->wake_cpu" constraint in proxy_needs_return() > > Yeah, that's a sound call, the shortcut isn't necessary and just adds > complexity. > > * sched/core: Allow callers of try_to_block_task() to handle > "blocked_on" relation > > Seems like it could be pulled up earlier in the series? (with your first change) > > * sched/core: Prepare proxy_deactivate() to comply with ttwu state machinery > > This one I've not totally gotten my head around, still. The > "WRITE_ONCE(p->__state, TASK_RUNNING);" in find_proxy_task() feels > wrong, as it looks like we're overriding what ttwu should be handling. So the reason for that is, we can have: CPU0 (owner - A) CPU1 (donor - B) ================ ================ mutex_unlock(M) atomic_long_try_cmpxchg_release() /* B is just trying to acquire the mutex. */ ... schedule() /* prev = B, next = B; B is blocked on A */ find_proxy_task() ... owner = __mutex_owner(M); if (!owner && task_current(rq, B)) __clear_task_blocked_on(p, NULL) return B __set_task_blocked_on_waking(B, M); ... /* B starts running without TASK_RUNNING. */ /* nop since !B->blocked_on */ /* * Scenario 1 - B gets mutex and then sets * TASK_RUNNING on its own. */ /* Scenario 2 */ wake_q_add(B) wake_up_process() ttwu_state_match() /* true */ B->__state = TASK_RUNNING; So in either case, task will wake up and set TASK_RUNNING so we can just do the pending bits of wakeup in __schedule(). I think even without an explicit TASK_RUNNING it should be fine but I need to jog my memory on why I added that (maybe for caution). If the task fails to acquire mutex, it'll reset to blocked state and go into schedule() and everything should just work out fine. > But again, this is only done on current, so it's probably ok. > Similarly the clear_task_blocked_on() in proxy_deactivate() doesn't > make it clear how we ensure we're not proxy-migrated, So the rationale behind that was, we should *never* hit that condition but if we are, perhaps we can simply do a move_queued_task() back to "wake_cpu" to ensure correctness? > and the > clear_task_blocked_on() in __block_task() feels wrong to me, as I > think we will need that for sleeping owner enqueuing. Yes, for sleeping owner that is not the ideal place - I completely agree with that. Let me go stare at that find a better place to put it. > > But again, this didn't crash (at least right away), so it may just be > I've not fit it into my mental model yet and I'll get it eventually. Yeah, but then you lose the "blocked_on" chain when you deactivate the donors only for it to be reconstructed back by running the task for a little bit and re-establishing that relation so although it might not have crashed (yet!), it is pretty inefficient. I'll go stare more at that. > > * sched/core: Remove proxy_task_runnable_but_waking() > > Looks lovely, but obviously depends on the previous changes. > > * sched/core: Simplify proxy_force_return() > > Again, I really like how much that simplifies the logic! But I'm > hesitant as my previous attempts to do similar didn't work, and it > seems it depends on the ttwu state machinery change I've not fully > understood. Highly intertwined indeed! I'll try to add more comments and improve the commit messages. > > * sched/core: Reset the donor to current task when donor is woken > > Looks nice! I fret there may be some subtlety I'm missing, but once I > get some confidence in it, I'll be happy to have it. Ack! I too will keep testing. Btw, do you have something that stresses the deadline bits? I can't seem to reliably get something running with lot of preemptions when holding mutexes. > > Anyway, apologies I've not had more time to spend on your feedback > yet. I was hoping to start integrating and folding in your proposed > changes for another revision (if you are ok with that - I can keep > them separate as well, but it feels like more churn for reviewers), > but with Peter sounding like he's in-progress on queueing the current > set (with modifications), I want to wait to see if we should just work > this out on top of what he has (which I'm fine with). Ack! None of this is strictly necessary until we get to ttwu handling the return migration so it should be okay. If you are occupied, I can test and send these changes on top separately too to ease some load. > > As always, many many thanks for your time and feedback here! I really > appreciate your contributions to this effort! And thanks a ton for looking at the tree. Much appreciated _/\_ -- Thanks and Regards, Prateek