From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazon11012042.outbound.protection.outlook.com [52.101.53.42]) (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 C7255312825 for ; Tue, 19 May 2026 15:47:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.53.42 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779205649; cv=fail; b=DMjOYt1zG7P27Urps6ggDAs7iGqqHa2mPhsPAl9iiTO48NBPykQ548zawqPNEnvzHs24jQ08h8hujZY4cXljnpCk6xXJCWNHEgbCvdgU7nplho1bQ1frZXV5x8ttDia52VqdIY5sHQteOlxFLK15mROOT6Clt4JY4qwPTq074/k= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779205649; c=relaxed/simple; bh=/Y2pRYum67ZjflLAFpZU/BoxASHVORrClLzXigwbOmw=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=h8GjTdZ37aldw8pnoZAFSCTz0qDFo07uaMi/2Z9yJ0dgLAi6iCMA+Hauow7o5cN/gRrkVzfYKCruehnzd13Quzfw5TaDzVlelz0CJEZ8GF81y47W6bTtRvd9vOj/r1j+gMJYCfsIfnx9gvyKEPW6cF/5tnHLf4OsRr7sxfLJVLg= 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=YTvF+gFx; arc=fail smtp.client-ip=52.101.53.42 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="YTvF+gFx" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SRRy3exz90C573ovzyAqODCCzIWMy+u1eKT7klzlZ0hu0zBB88BwbZeaMkpcgiuzTdYwXZuPVTE/Vahgrd99msZsedK2bDl4AZWezCUd6LbeqBBlmaaBjSrW9m2T7XNoFAfrLvGeImkBmVc1R2rzTq53C0d3Mf/oFsbCD94y2YnurTDXVpKzggcvnabDahaH/IWWL8pBs92DyfZ+B7kyOxplktkUXcnKvzsNk4Qd/MRwxuMbg6OR20HGBltMUKU5pD0g/dK9aDBtdgB9Y4X/I/rFlEdZaAGM8xoB5qmb03lf63mYiCvGz5OMiRscLl7jjkDf1+ALBrO5njABS5RQDw== 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=Hum7IovVdZG0K+6gzxvONaaUau2ntvrAlzA4j5SuI6o=; b=AW+zA05AQBLdZ2J4D1N2d8wyeagfobhMdHgUQ3b1YjTkXzSGqMpOrg4C0nMd0wQjw7wxi4yhNRv5UMLCqjeApQsfkIt7Zl/iXXcGfBLka2z9/Zr6R7tAImneMAV6aI97Gj6w4SL+XcWekCSgmBs8JLte6Cm5TI0IqZ7R62bwbiKToO+qWAinkxDJg8niaEXVxrIDVRYu3NPELAQ4k1uJjLnq7BpwPtRmCMQQE8VrlpJQlUAmxVij8gib/Hk4jCenvQD/BYde4dJGvgBYIuAKJ926KtYU6zHJgVfbwrXYZFDUNibD+ogeBuyfQ+yA1sCfrjr2txthZUw8dIAtbDSmgA== 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=Hum7IovVdZG0K+6gzxvONaaUau2ntvrAlzA4j5SuI6o=; b=YTvF+gFxtugtp7pXNOzMKKapaIoIN1Fw+dXzjb5wm60H/XY1LgqOJDZJhhv15PVS23KxWIIRC3GycJdo0Zh5Uk3iFYjpRLF5CVzlxH9Fk/gl/S6me4PkwhHvnHFMATtq9Eu6fIPT0hI28Y4Y8LX4Okx3O/USsWR7SAnu1w/JZ4g= Received: from CH2PR10CA0009.namprd10.prod.outlook.com (2603:10b6:610:4c::19) by CH8PR12MB9768.namprd12.prod.outlook.com (2603:10b6:610:260::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.25.23; Tue, 19 May 2026 15:47:19 +0000 Received: from CH2PEPF000000A0.namprd02.prod.outlook.com (2603:10b6:610:4c:cafe::12) by CH2PR10CA0009.outlook.office365.com (2603:10b6:610:4c::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9913.12 via Frontend Transport; Tue, 19 May 2026 15:47:18 +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 CH2PEPF000000A0.mail.protection.outlook.com (10.167.244.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.48.11 via Frontend Transport; Tue, 19 May 2026 15:47:18 +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.41; Tue, 19 May 2026 10:47:06 -0500 Received: from satlexmb07.amd.com (10.181.42.216) 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.41; Tue, 19 May 2026 08:47:05 -0700 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.41 via Frontend Transport; Tue, 19 May 2026 10:46:59 -0500 Message-ID: Date: Tue, 19 May 2026 21:16:58 +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 v29 7/9] sched: Add blocked_donor link to task for smarter mutex handoffs To: Peter Zijlstra , John Stultz CC: LKML , Juri Lelli , Valentin Schneider , Connor O'Brien , Joel Fernandes , Qais Yousef , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , "Daniel Lezcano" , Suleiman Souhlal , kuyo chang , hupu , References: <20260512025635.2840817-1-jstultz@google.com> <20260512025635.2840817-8-jstultz@google.com> <20260519143238.GB2934902@noisy.programming.kicks-ass.net> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260519143238.GB2934902@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF000000A0:EE_|CH8PR12MB9768:EE_ X-MS-Office365-Filtering-Correlation-Id: 271ad4fc-cd7c-437e-7221-08deb5bde823 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|82310400026|36860700016|1800799024|4143699003|56012099003|18002099003|22082099003|11063799006; X-Microsoft-Antispam-Message-Info: zm+XYqBh63SvaxX6T2IxFNZVbbQ8gBP6TW7kamOY+nCNkcvplVrCZ+SBdTsGODx3VIqEiiHJmmV5D39rAKdooT5jHwZ4138qudGyT4jsyHwzP8KMrgrHKJnOGUrZIFlV61dBqeWcYXIkhqQvTtO/fBeLJzL8GH+m/N8L06ChHFQD2Nej2lKCkuPLgMXvad/wxcix50H+A/HJVdLrXJIKQA7DUsG0+kChjaLMyeo0Op+yyXMgpIog6JAqlSpsCRYXh4GH3v0Do2CL0foNUu0sA/2wgTdi63AB+2MWE4ZIfbcWs9FG0I3ooVpbOI1eFcdcKCx0AycK5iQYVsnX2kVPHNLIKujnAdHyUaL/KCvCWuiOS+RS5M9cujeLdtHv8O7UJrFa8Zi3CEfVDKxZogE6XMWUbsv8BNzCxc01hs4OO38dYV0uxLT9/p1+6aYkzXjh8kZy9yzTxMhpYIg6eVrLuF7Cefoia9c6AlGHWDowbsnWiieFuLAS+6XB9q1hsTdfNhqoVBqPweRGNlRO+2yJ75y0wycDQtleZdZsfmHJU9ACP4H+6Wk0Vhu2+2U70Owb1E0zzAO5Uop6O2I7xl1MvSX0jgzi5Nv9GnFnuwR51p5JdhITU8r89w26uPzHdReAmhpPWLynJYqmesxSn5vW/eYACOYIBtZN2bKT4vsz2cSQ0nBSS4FC69qlNlbWyJsnmgPAkmfFZtbVgIEsG8JiRk9xjANt9pJ8dhUJl2xZ4zg= 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)(376014)(7416014)(82310400026)(36860700016)(1800799024)(4143699003)(56012099003)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: xXDySo1/Itwp5gpEYeLEelRbwzLb6apTcbTXXg1aIVZltuagZcMSm3Eqjldk6GeTAIgkNJunFnr+VPXYzi0fGK3VddEMKLYBouFmEarnw5a5kX8Cpi/0aATpdC+sXD7+NEbuNLBJ8IgXtAk1EEnHX/RqOXZVhmMBwW3+9J4Oea0TiSjjycE1XBJcyp+6i/ZexzjBgM+PaANRBnKvZPekuzEUOIU83ysmzofC6+4WK3Z2hAA9XHYvEhif26kUiT+IPghzOE/SGEesjESQb3D6zMMCwgBFUmVeT3/16v2mY5bDWo455dIbHivoJ8h5BAh1h2B8rGpYW5/ueHnwIdoL47ZyNz4klz47pQHmIB9hVj/H6q7ZRVjnJ+MH4xMT02308h9ZxFu1L+BoE7KQ0+5VhkhRlymWNHq1f68ZpcT6oGsA6ZOq08a4INbjEXIWY0hb X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2026 15:47:18.0737 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 271ad4fc-cd7c-437e-7221-08deb5bde823 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: CH2PEPF000000A0.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB9768 Hello Peter, On 5/19/2026 8:02 PM, Peter Zijlstra wrote: > This then brings us to the consumer side of things: > >> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c >> index 09534628dc01a..0064b724ccda3 100644 >> --- a/kernel/locking/mutex.c >> +++ b/kernel/locking/mutex.c >> @@ -980,7 +980,7 @@ EXPORT_SYMBOL_GPL(ww_mutex_lock_interruptible); >> static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip) >> __releases(lock) >> { >> - struct task_struct *next = NULL; >> + struct task_struct *donor, *next = NULL; >> struct mutex_waiter *waiter; >> DEFINE_WAKE_Q(wake_q); >> unsigned long owner; >> @@ -1001,6 +1001,12 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne >> MUTEX_WARN_ON(__owner_task(owner) != current); >> MUTEX_WARN_ON(owner & MUTEX_FLAG_PICKUP); >> >> + if (sched_proxy_exec() && current->blocked_donor) { >> + /* force handoff if we have a blocked_donor */ >> + owner = MUTEX_FLAG_HANDOFF; >> + break; >> + } >> + >> if (owner & MUTEX_FLAG_HANDOFF) >> break; >> > > AFAICT this is racy since we don't have preemption disabled. > > So we can observe ->blocked_donor (A) set, or (B) unset. > If (A) we can schedule() right after this (and before taking > ->wait_lock) and it can be unset when we resume running this task. Or > (B), the exact opposite. > > Now, (A) is harmless, because if ->blocked_donor becomes NULL, the > hand off code falls back to picking the first on the wait list and > things just get on. > > *However*, (B) might be a problem, because then we will not have the > HANDOFF bit set even though there is in fact a donor we need to hand off > to. I don't think it is that big of a problem: __mutex_unlock_slowpath() sees current->blocked_donor as NULL but just before it can do: atomic_long_try_cmpxchg_release(&lock->owner, &owner, __owner_flags(owner)) it is preempted and comes back with a ->blocked_donor. Once we grab the wait_lock, we realize there is a ->blocked_donor link and we wake it up instead of first waiter which goes and grabs the lock once it hits mutex_trylock() for !owner case. If a concurrent mutex_lock() races with this sequence, the ->blocked_donor that was woken up sees the new owner and goes to proxy that. With guard(preempt)(), we see a stable ->blocked_donor as NULL, and we wake up the first waiter after clearing the "owner" from lock->owner. If a concurrent mutex_lock() races, it still grabs the mutex and now it is just the first waiter that realizes it has to go proxy the task that stole the lock. One wasted wakeup is incurred in both cases but it seems like no biggie. Maybe I don't understand the subtleties but stabilizing it against preemption is definitely a good move since it saves this debate :-) > That is, we need this on top, no? > > --- > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -1242,8 +1242,14 @@ struct task_struct { > #endif > > struct mutex *blocked_on; /* lock we're blocked on */ > - struct task_struct *blocked_donor; /* task that is boosting this task */ > raw_spinlock_t blocked_lock; > + > + /* > + * The task that is boosting this task; a back link for the current > + * donor stack. Set in schedule() -> find_proxy_task() and only stable > + * under preempt_disable(). > + */ > + struct task_struct *blocked_donor; > > #ifdef CONFIG_DETECT_HUNG_TASK_BLOCKER > /* > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -990,6 +990,14 @@ static noinline void __sched __mutex_unl > __release(lock); > > /* > + * Ensures the proxy donor stack is stable across unlock and handoff. > + * Specifically, it avoids the case where current->blocked_donor is > + * NULL when it is inspected while doing the unlock, but a preemption > + * before taking the wake_lock would make it set and a hand-off is > + * missed. > + */ > + guard(preempt)(); > + /* > * Release the lock before (potentially) taking the spinlock such that > * other contenders can get on with things ASAP. > * > @@ -1063,7 +1071,8 @@ static noinline void __sched __mutex_unl > __mutex_handoff(lock, next); > > raw_spin_unlock(¤t->blocked_lock); > - raw_spin_unlock_irqrestore_wake(&lock->wait_lock, flags, &wake_q); > + raw_spin_unlock_irqrestore(&lock->wait_lock, flags); > + wake_up_q(&wake_q); In that case, can't we simplify this to: if (next) wake_up_process(next); and save on the wake_q enqueue dequeue overheads? > } > > #ifndef CONFIG_DEBUG_LOCK_ALLOC -- Thanks and Regards, Prateek