From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazon11011038.outbound.protection.outlook.com [52.101.62.38]) (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 CAEB8371D1E for ; Fri, 3 Apr 2026 15:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.62.38 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775230789; cv=fail; b=gMOQFz9UYZGKfVcE9y2zPcJDXs2+0uQvuv4nduPFEfjF33VpLRXsaKDCjW0F38RJebHg8kOY11ZWNTm11aXqr8KAfK9sRCrDhWaEyMOfUXVdhnfiCat4mRifdn7hRT2Uye9CTd4naTDOXDYSDPSlS0AM5Q33oKoArumZngYa3IU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775230789; c=relaxed/simple; bh=m1w9Hb2NASFbaiPkkvOSYGHv1amfSqxmLPNjgCNZwcc=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=QPwzk/pb7U2Psf28mxob4pbFKYkSPnaTI9pbUWb8TU+qqzAVYxOihfLWgMS8UgWZdcnwgIMbCfPZn4HF+bo85fYtfc2TE7YkGkoVe7YF9QHIT4PKPnfhNfeC/3MR/ubNwJ/rUPZ8pYc4UgKOsYb0SlceVb/hafLHg6Ur31v5w8g= 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=p0YPXgUu; arc=fail smtp.client-ip=52.101.62.38 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="p0YPXgUu" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SDmFdzHvKpQfMmralh5GLGYgKx0f63B3LRViXy6/uDsTZd6vf0Fsn4l8JR2qnjd7dtfmUlpTeZ3Oow7MUuPmvvwe3yXlMzO870f2bX14iH8TM9SBIkG4Vnn/Dwm2UGAPQbGmXKAF9jeUbxk7aw2dfG8QeqHctm5oQ4KIr0EY0IzMr3jhXMUB8y43u241lzzWXPI815AxzZfo2SFBBdOauLXOUHp7NTwehy7bfyrjLGHn06ZkuASz14imWSzjF4jemGi4oFv0Jf+yIlC3y8DA5UFS56BBFhL6yndyIRje7diuBRvFQWKFimiNp2+lo6Cy/Twxw/bibLuS/CEL9m4Njw== 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=o6aA+Ds5EUdgOEPxuNFRJYmELw3W01Z5zfyZ/sFpEos=; b=g8tECgMf7PIspz4lu1A7pA+UhvsL+CUCOZ5oHmAXnIl0IyO2lbms80po2ySbJETVR+kabbXy+mLzzid99F0R/XRs37iNp+EZOXA1AhtoC4fHTupk8xEMRrq2z2pYXeCiP7glp9IhnlCqEV7udDrLXwAAir4d+VWEpKjWZqx3hOxRHtRkotBOne6YO9Su6sNpmMQMHEbRIl6uzEQklaLG7gwvLLRAHdRDz5IDHFYDwot+9b7T/U8EW8QL7Eg5/gc4ULN1FU5CtAHUK+YMOUuZrC8SRzkRah9TUo5wcYshC9Ux9MEDmsIyFK8rdKVEsYnd9FPNhDN5e+Zuz+1GqXVbfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=infradead.org 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=o6aA+Ds5EUdgOEPxuNFRJYmELw3W01Z5zfyZ/sFpEos=; b=p0YPXgUuCANzpRDFo5wo9GDYR5f+77xuuN73tr0o7mF5acQmeuTWBC0ryHywm+8vDyJDWzYtYPlOlcNspEJvAp1ejUEQX0gdi7/Y7vRL0qCgGlsCLV4+t7WsUgCm0rutTaltwuRQJJeEMGB9EUjvn86L6z/ISUeHjLBUFGi6nW0= Received: from BYAPR02CA0057.namprd02.prod.outlook.com (2603:10b6:a03:54::34) by CH3PR12MB9148.namprd12.prod.outlook.com (2603:10b6:610:19d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.20; Fri, 3 Apr 2026 15:39:42 +0000 Received: from CO1PEPF00012E64.namprd05.prod.outlook.com (2603:10b6:a03:54:cafe::2c) by BYAPR02CA0057.outlook.office365.com (2603:10b6:a03:54::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9769.20 via Frontend Transport; Fri, 3 Apr 2026 15:39:41 +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 CO1PEPF00012E64.mail.protection.outlook.com (10.167.249.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.17 via Frontend Transport; Fri, 3 Apr 2026 15:39:40 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Fri, 3 Apr 2026 10:39:40 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 3 Apr 2026 10:39:39 -0500 Received: from [172.31.184.125] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 3 Apr 2026 10:39:32 -0500 Message-ID: <0f5b0dd9-ef6e-462b-ac89-6f37c4261241@amd.com> Date: Fri, 3 Apr 2026 21:09:31 +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: Peter Zijlstra CC: John Stultz , LKML , 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: <33e60181-1809-44e1-bc4c-8ac7f79d49d6@amd.com> <20260327160017.GK3738010@noisy.programming.kicks-ass.net> <1515d405-62fc-4952-842f-b69e2bf192c0@amd.com> <20260402155055.GV3738010@noisy.programming.kicks-ass.net> <20260403095225.GY3738010@noisy.programming.kicks-ass.net> <1d2d4596-93d6-4d87-babc-084b8d6c2d98@amd.com> <20260403112810.GG3738786@noisy.programming.kicks-ass.net> <5e2337e7-24d8-4cc7-a86d-b8f5a19fb3ce@amd.com> <20260403143819.GC2872@noisy.programming.kicks-ass.net> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260403143819.GC2872@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: kprateek.nayak@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00012E64:EE_|CH3PR12MB9148:EE_ X-MS-Office365-Filtering-Correlation-Id: fe475732-219b-4eac-9d0d-08de9197388b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|36860700016|82310400026|22082099003|56012099003|18002099003|13003099007; X-Microsoft-Antispam-Message-Info: Hca8ylk0x0f+RKnfV1XMnFBtVZrmlk8UOfV/TVhfMhNqFzL7h75C0onYZhE88m5MrbQHyXmesuQGSv34wRj8NBHEAB/8krTbm5n08UT6Z6Zy2tzTFcJWwm5jGGIb0IX8Q+r2WuNn4iQT9lJyQgiHrWd8qvWjY/m5LnQ8cLERQ1YuGDDtY48R6CtDRyzXxPRqsI3/Nlt/FJXE7DJHV9Dk9tmSVbq556TI6Z9OGeGQYS4lpUfzg2GZkLwCazVj8k2HYt3LvdtEHbiBcKaFpwk85/Lpl1jfmE8TCzAOHOgWYHr2y6XytcAzwL4OCud14e7qiXmUnHrLbCHrFreJjfc+3hAjsW+uJnuaTCfzwk4P6uj/8iAObX0PXtHhwY677+O/tZ7+jYMaHuIj+AsM8+cOyb08JgiyaDM0a1abI5vg+O0NJSQeA0F7nD+fv4mw7D1VNGXMCF3eaTr060MBLaii3NCxwpyT9cHnHeUkI9Gxs8XB/2EpwusITbTk3bYely9jhcauAjeu4SjbIX5HUV3TSSNXyWWtglAPgZANLjxVNg0SrPvFvVzEo7DgxSXrw5+oui3Mmx8CUwUN2qXL00u+7moEP+fgAu1efOhXC7NRQb2BUJ8qgmpoh5HSBiM5ZDMAgnp9KO/VMd0eUApYMtAHx4BrVb1ruJlyrNmMlz7F+AoY2L1PeqtDwHot2XruljI7i0b8xKYjZDi6ry5UpY0L5PxxrewmBgZwCClA1h2tzOPMnP1ci3xvqS57DXE6uQqj8JnIy2qrngL2yRfA8LUfyJUFk9Kk6J5RWIO9Gzta+AY= 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)(1800799024)(376014)(7416014)(36860700016)(82310400026)(22082099003)(56012099003)(18002099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +x37l3956wvh0+wDL+GajcpPTiEcbFwblTCuk8wqEBx3X8gGp2kT/6VNy26rInOKvuah1gKiW5Q9QOZcnv2MFbe/6jDREK35nTcVvOt/zKboNQLxn/o0HdgKkWyhNKyuYf9INIoZWuujMkg5R7sROClz2P25iN7nw9kwV1Ax4e3x/yyWCBMg3jhoxNWYTVpFK0/lZNhiQ4uumq7jYIe4Iq3dzymPibyhTS1AUd1LNzOtCNf//cdJRKUhe1ikfUwfFF1rWoMBHEiKxplGreY9Y4B7uXxTj6WPIN9Z9ua4MKnBYYwkhWFgF6Oc3bTghiSh92Ad7YXy5/jpQqiAFY423rOnsRG6O6canqaN4qf/gxGaznnWBNDvY+hYLRZ0v/iGZixpPV4QUrJRMK+oCO8MhlBEyyAvJV4pxHxWgsLwdx84xzi5wst8Fq6ZsgpVgvTg X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2026 15:39:40.6860 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fe475732-219b-4eac-9d0d-08de9197388b 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: CO1PEPF00012E64.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9148 Hello Peter, On 4/3/2026 8:08 PM, Peter Zijlstra wrote: > On Fri, Apr 03, 2026 at 07:13:29PM +0530, K Prateek Nayak wrote: >> Hello Peter, >> >> On 4/3/2026 4:58 PM, Peter Zijlstra wrote: >>> On Fri, Apr 03, 2026 at 03:55:22PM +0530, K Prateek Nayak wrote: >>>>>> @@ -4256,6 +4277,15 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) >>>>>> */ >>>>>> smp_cond_load_acquire(&p->on_cpu, !VAL); >>>>>> >>>>>> + /* >>>>>> + * We never clear the blocked_on relation on proxy_deactivate. >>>>>> + * If we don't clear it here, we have TASK_RUNNING + p->blocked_on >>>>>> + * when waking up. Since this is a fully blocked, off CPU task >>>>>> + * waking up, it should be safe to clear the blocked_on relation. >>>>>> + */ >>>>>> + if (task_is_blocked(p)) >>>>>> + clear_task_blocked_on(p, NULL); >>>>>> + >>>>> >>>>> Aah, yes! This is when find_proxy_task() hits deactivate() for us and we >>>>> skip ttwu_runnable(). We still need to clear ->blocked_on. >>> >>> I wonder, should we have proxy_deactivate() do this instead? >> >> That is one way to tackle that, yes! > > OK, lets put it there. At that site we already know task_is_blocked() > and we get less noise in the wakeup path. > > Or should we perhaps put it in block_task() itself? The moment you're > off the runqueue, ->blocked_on becomes meaningless. Ack but I'll have to point you to these next bits in John's tree that handles sleeping owner https://github.com/johnstultz-work/linux-dev/commit/255c9e933edf5b86e29f9fbde67738fc5041a862 Essentially, going further, when the blocked_on chain encounters a blocked owner, they'll block themselves and attach onto the sleeping owner - when the owner wakes up, the whole chain is activated in one go restoring proxy. This is why John has suggested that block_task() is probably not the right place to clear it since, for the sleeping owner bits, we need to preserve the blocked_on realation until ttwu(). I have some ideas but let me first see if I can stop them from exploding on my system :-) > >>>>> >>>>>> cpu = select_task_rq(p, p->wake_cpu, &wake_flags); >>>>>> if (task_cpu(p) != cpu) { >>>>>> if (p->in_iowait) { >>>>>> @@ -6977,6 +7007,10 @@ static void __sched notrace __schedule(int sched_mode) >>>>>> switch_count = &prev->nvcsw; >>>>>> } >>>>>> >>>>>> + /* See: https://github.com/kudureranganath/linux/commit/0d6a01bb19db39f045d6f0f5fb4d196500091637 */ >>>>>> + if (!prev_state && task_is_blocked(prev)) >>>>>> + clear_task_blocked_on(prev, NULL); >>>>>> + >>>>> >>>>> This one confuses me, ttwu() should never results in ->blocked_on being >>>>> set. >>>> >>>> This is from the signal_pending_state() in try_to_block_task() putting >>>> prev to TASK_RUNNING while still having p->blocked_on. >>> >>> Ooh, I misread that. I saw that set_task_blocked_on_waking(, NULL) in >>> there and though it would clear. Damn, sometimes reading is so very >>> hard... >>> >>> Anyhow, with my changes on, try_to_block_task() is only ever called from >>> __schedule() on current. This means this could in fact be >>> clear_task_blocked_on(), right? >> >> Yes, that should work too but there is also the case you mentioned on >> the parallel thread - if ttwu() doesn't see p->blocked_on, it won't >> clear it and if ttwu_runnable() wins we can simply go into >> __schedule() with TASK_RUNNING + p->blocked_on with no guarantee that >> same task will be picked again. Then the task gets preempted and stays >> in an illegal state. >> >> Clearing of ->blocked_on in schedule also safeguards against that race: >> >> o Scenario 1: ttwu_runnable() wins >> >> CPU0 CPU1 >> >> LOCK ACQUIRE >> [W] ->blocked_on = lock [R] ->__state >> [W] ->__state = state; RMB >> [R] ->blocked_on >> [W] ->__state = RUNNING >> >> /* Synchronized by rq_lock */ >> >> MB >> [R] if (!->__state && >> [R] ->blocked_on) >> [W] ->blocked_on = NULL; /* Safeguard */ >> >> >> o Scenario 2: __schedule() wins >> >> CPU0 CPU1 >> >> LOCK ACQUIRE >> [W] ->blocked_on = lock [R] ->__state >> [W] ->__state = state; >> >> /* Synchronized by rq_lock */ >> MB >> [W] __block_task() >> >> MB >> /* Full wakeup. */ >> [R] if (->blocked_on) >> [W] ->blocked_on = NULL >> > > Oh Boohoo :-( Yes, you're quite right. > > Is find_proxy_task() that is affected, so this fixup should > perhaps live in the existing sched_proxy_exec() branch? > > Something like so? > > > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -2222,6 +2222,13 @@ static bool block_task(struct rq *rq, st > { > int flags = DEQUEUE_NOCLOCK; > > + /* > + * We're being taken off the runqueue, cannot still be blocked_on > + * anything. This also means that delay_dequeue can not have > + * blocked_on. > + */ > + clear_task_blocked_on(p, NULL); > + Oh! I remember why we couldn't do this - if we clear the "blocked_on" via proxy_deactivate(), we might be delayed on the owner's CPU *outside* of the task's affinity. In that case, we don't want to re-enqueue it there since it'll violate affinity and the "blocked_on" relation forces it down the sched_proxy_exec() path in ttwu_runnable() which will fix it via a full wakeup. > p->sched_contributes_to_load = > (task_state & TASK_UNINTERRUPTIBLE) && > !(task_state & TASK_NOLOAD) && > @@ -6614,7 +6621,7 @@ static bool try_to_block_task(struct rq > if (signal_pending_state(task_state, p)) { > WRITE_ONCE(p->__state, TASK_RUNNING); > *task_state_p = TASK_RUNNING; > - set_task_blocked_on_waking(p, NULL); > + clear_task_blocked_on(p, NULL); This is not strictly required - since we set the "*task_state_p" to TASK_RUNNING which modifies "prev_state" in __schedule() ... > > return false; > } > @@ -7043,6 +7050,14 @@ static void __sched notrace __schedule(i > if (sched_proxy_exec()) { > struct task_struct *prev_donor = rq->donor; > > + /* > + * There is a race between ttwu() and __mutex_lock_common() > + * where it is possible for the mutex code to call into > + * schedule() with ->blocked_on still set. > + */ > + if (!prev_state && prev->blocked_on) > + clear_task_blocked_on(prev, NULL); ... we'll just end up seeing !prev_state here and clearing it. We can keep them separate too to make it very explicit. No strong feelings. > + > rq_set_donor(rq, next); > if (unlikely(next->blocked_on)) { > next = find_proxy_task(rq, next, &rf); > -- Thanks and Regards, Prateek