From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazon11011037.outbound.protection.outlook.com [52.101.62.37]) (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 71858211A05 for ; Tue, 10 Mar 2026 04:17:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.62.37 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773116261; cv=fail; b=XkZJ6otdRO3Pp+QACdOwzX1daOxMYK8nRmqdbuk3zSe4GJh6h+W61jN1dag8iKY9BTDdqRzRi+m6JFQqxgbpRXSkr9Wm+SJNJn1pVEoHKa8frBTyauQ+rMRxZQaf40YyVOYWFkKFgKPWnRiO1hXoIQBpFg6qhWA3FApQ2i34hAw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773116261; c=relaxed/simple; bh=Kefr4j0+DSAymwwAuq+bOKuKRREOIygoXPecTsKbkyU=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=g5wEzzWSJULQu8rQ+BfX720xnaNHEZUABSiaijNDq/1d/O8JK8If1PUTnlKerlb+B+lA1RUYwFyhy622vo1OlYakkctOun83VIj6vRL6Vie9tYipRr1MQk/eiH8uo/ACDcrp8ljkACcwhtVfhwVYMs9Zf1OGBgva/s/+Yj5pujM= 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=ccF78uej; arc=fail smtp.client-ip=52.101.62.37 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="ccF78uej" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IkiyVpFDc83LDZC8jHO8w046+o+dWe6+D8AWq8LlBarDzWXQfhPYjZEKp8TXTVKJeK79pnR5qDjWpX6X+6c+KgpdVYjmGEIiOgzaafV9C0kfVrKpU/mDCck/sDtx3HL2efJ8irNawMz+nq7OODRbXexPQjBJayP9U+Mi/qD4SmgG07CcgjcVGgj0ugJl7MixiKCWEs6eJlSQw0dHOgfkE/QGKtA73P5rXvXt5ZRSTlT6qpPqKjrDz8Or2kaGML+XanZ4SIO/kSMVaQWxPjtYYAuMiuqEka7vkJC45kuRYSDqQBKx49J1sDTKV2oEdRVcXMDy2FlvgHIiCfS16eieMw== 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=zGXBMlTDCoqBK2x5plBG72cO+WsKR+yVmbXGINcZd6Y=; b=oF48GuRHFBARz7So1wFVjPV63GQwAVMLdFb/VAE4IPAcaiZ2jNkTOGwAxk3RYoOka3XrjbVwajkpNWzmczETJ3iaVlBQub6Lqe3lH8yQhQlv5/vvSljICcBHfsiZDpkY5jHDtBj2hMYfObVYM4pJ4BBEFSbUnQ9vwhuUVDbw+7i62Qd1Qnhn+8nbPpZrvjLAG7cOLx0dgw2F/wzLY8vK/+WUuyRRwokvHaa8HLY9DFwWzV6jAK9DDZxqbsoceEtYQMCyvD1NV+5yvbTN3Q3Zbuvz0dnBhO77HeJ0qLF8WEalufRbRSt1HeJ+J8/bLcAnv7uxQ0P36R2RWy0E2qU5qw== 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=zGXBMlTDCoqBK2x5plBG72cO+WsKR+yVmbXGINcZd6Y=; b=ccF78uejD1VRUYtSYLSuDTC2JxjDSLfDXbYWfkOImkmEi+FPFB7qB+Ukiy0cR7P9rhfUNadhoWn75BTrDNRAOGEo/tGAw1XpgEJLAAZu7sj9rc7a1cwc0zgOUAeTjGFeZ/axyisz+WaOgYsJM4T+u7LnZD5Nc/RFGJhQQFD44iw= Received: from MW4PR04CA0056.namprd04.prod.outlook.com (2603:10b6:303:6a::31) by DM6PR12MB4092.namprd12.prod.outlook.com (2603:10b6:5:214::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Tue, 10 Mar 2026 04:17:36 +0000 Received: from SJ5PEPF00000206.namprd05.prod.outlook.com (2603:10b6:303:6a:cafe::47) by MW4PR04CA0056.outlook.office365.com (2603:10b6:303:6a::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Tue, 10 Mar 2026 04:17:15 +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 SJ5PEPF00000206.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Tue, 10 Mar 2026 04:17:35 +0000 Received: from satlexmb10.amd.com (10.181.42.219) 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.17; Mon, 9 Mar 2026 23:17:29 -0500 Received: from satlexmb07.amd.com (10.181.42.216) 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; Mon, 9 Mar 2026 23:17:29 -0500 Received: from [10.85.46.243] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Mon, 9 Mar 2026 23:17:22 -0500 Message-ID: <1bfcab94-c6bd-437a-92ae-333ad0adaf74@amd.com> Date: Tue, 10 Mar 2026 09:47:21 +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 v24 06/11] sched: Handle blocked-waiter migration (and return migration) 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: <20251124223111.3616950-1-jstultz@google.com> <20251124223111.3616950-7-jstultz@google.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: SJ5PEPF00000206:EE_|DM6PR12MB4092:EE_ X-MS-Office365-Filtering-Correlation-Id: f7fb5522-c83c-4d24-c907-08de7e5bf593 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|7416014|82310400026; X-Microsoft-Antispam-Message-Info: XYpRH/pPuoxTnL6begOK39KcBLDSsEXd5csNAoxMNPbAn8tmXBjaBDXyn7POiy4MV1ioFGykpqbCYE4j6CbQaYZJ5Xw1eJTDOsFOQ7VJmvv66khBI7u4cqY7DyBnjTVrPubO/c1w0lZ7BgPCOEfpgToYfHKfR1nt3h4XjxhyQr6ATEYOO4XkUHm/13Vj7hcpKEiTy1iqtW4BGShjDiKRIf4iZgOlKkPLgQICd8JNHe3yIRm+85q3OF6Jx799P5b0L7cNQy09GoB6ISMhGAEKD9QRL8mbSPGxb6/7/iBlLkF/MxCbLBt0mXfFYXZFOrKdtTncIuY3yEQjAErQd+ySKxr/GnjpDaKG1BqvSJQD7WIr8sd14aMi+wjDCH2gU6D/JPylQMrtp4uP0Rhl/0he7E7xYAK8ohX/CVzqzw2xKXqHK5gUMpgPV9Y0ztXYiVNJoxLbkuSJgiRHoI9PcMXZhER3ZmzVyBF34UpjOgdqSc/CZCsM8M+T74HIcbnxbvj1em+nDjvjk78HtFboq67q+YiK3zMjP4UhDWN9kPVEpArNkDa6aNL4SurzhlmxdrBOG9KFqtUAyt6zjdj5w6Q6gDd4Yxb1lZ6aN/1P3FjAiBBOmqz4YWTb+Ou3ARP3lpR6Tr3tHQNTZf6YrTZ7x/nX2RTgSYwbLsYwOOa7PExZgtvpgHt+qxlIGKvoHdyaylB5sBMNYtmtUAMSzXeN9ZlBm4+4OqdivS8pWAyC0rtnaFCFVqNCFIZ8RrFkOTR5pLesFhZLPYMJDjJPOaSc5yC+8g== 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)(1800799024)(36860700016)(376014)(7416014)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +CXy/BGN0qrZ3En2WW8jh5aeJTY10z2TeXHXpKW21NHD9V3BMcJUYufVjzrrZX/9u2RWS/saaXrHDSpnKo4Ovmw9SiIX3IXnzEV782Dbs6Va7mDonb1D/mqeSniQcMfDG9WxN+02o0BpmmBFmuc8iA9+L149jyiqFP0OAZQPnsS8zBOMB9b9eyXtBFlyFmYfDDZ+FSFY1JQv3gwVAu4ApwNNRHmYYBu6dHiqyIMpL7Nu+tVKDcjsNnhKztxwyMu9FDB0iGz/9zw+0qPcivZDG2rdcbjNhLx5pLTmnn782RAGnvfAXkTxTcuwxxQd9gYp3v8lcg4TTqaMXHyprFAYAx8n2bZpM1XpRoRgCE+i2gb59weYbG3f7rV1oI8xySebVOwyuWvCelYuIknNG95/OBEHGewez61Ej+pfRlm6IqU6VDFWfFzSYp6K+HU0bkK3 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 04:17:35.9679 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7fb5522-c83c-4d24-c907-08de7e5bf593 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: SJ5PEPF00000206.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4092 Hello John, On 3/7/2026 12:18 PM, John Stultz wrote: > On Mon, Dec 29, 2025 at 9:34 PM K Prateek Nayak wrote: >> On 11/25/2025 4:00 AM, John Stultz wrote: >>> + >>> + raw_spin_rq_lock(rq); >>> + rq_repin_lock(rq, rf); >>> + update_rq_clock(rq); >> >> I'm tempted to suggest extracting this pattern into a guard. We seem >> to always do the zap + unpin + unlock somewhere in the middle and >> lock + repin + update clock at the end of a function so how about: >> > [snipped guard logic] >> >> If the guard obfuscates the flow too much, I'm happy with the current >> approach as well but having the guard + a comment on top of its usage is >> lot more soothing on the eye IMHO :-) >> >> It also simplifies proxy_force_return() if my next set of comments aren't >> too horrible. I'll leave it to you and Peter to decide which is best. > > So first of all, apologies for being so slow to get to this! I very > much apprecaite your feedback here, but the first two months of this > year have been busy and I've not had the mental space to get my head > back into the proxy-exec details. I definitely did not intend to > neglect this for so long. > > So on your suggestion, I'm torn. It does make the code simpler, but > I've found some guard() usage to be less readable for me, as it can > hide some subtleties. > But I also felt this way when I first ran into scoped locking and I've > started to warm to that. > So maybe if it's ok, I'll leave this for now, but let's consider it > for a future refactor? Ack! Now that I look at it again, that guard does obscure the flow a lot for a few lines saved in the diffstat (if at all!) so I too think this can stay the same. >>> + /* >>> + * We drop the rq lock, and re-grab task_rq_lock to get >>> + * the pi_lock (needed for select_task_rq) as well. >>> + */ >>> + this_rq = task_rq_lock(p, &this_rf); >> >> So I'm failing to see why we need to drop the rq_lock, re-grab it via >> task_rq_lock() when we are eventually going to do a deactivate_task(). >> >> Once we deactivate, wakeup path will stall at ttwu_runnable() since it >> cannot grab the __task_rq_lock() with task_on_rq_migrating() so we >> should be able to safely move the task around. >> >> Maybe my naive eyes are missing something (and perhaps there are some >> details that arrive with sleeping owner stuff) but the following >> boots fine and survives a sched-messaging and test-ww_mutex run >> without any splat on my machine at this point: > > Hum. The reason we need the pi_lock is for select_task_rq(), and since > we hold the rq lock (which is under the pi_lock in the locking order), > we need to drop it to take the pi_lock and rq_lock via task_rq_lock(). > I know it's not pretty, but I'm not sure how your testing wouldn't > have blown up on the lockdep_assert_held() in select_task_rq(). > > Trying a simplified version (without the guard) locally leaves my > console filled with splats: > WARNING: CPU: 20 PID: 0 at kernel/sched/core.c:3746 select_task_rq+0xdc/0x120 > > But let me know if there's something I'm being daft about. Only one being daft was me since I forgot the whole pi_lock dependency for select_task_rq()! I'll start running with lockdep in my testing to spot these terrible suggestions early. Sorry for the noise and thanks a ton for testing that! -- Thanks and Regards, Prateek