From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011021.outbound.protection.outlook.com [40.107.208.21]) (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 6CBC8344DB8 for ; Fri, 27 Mar 2026 16:57:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.21 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630644; cv=fail; b=sMIPOtRLaQQpj2tgEhZ8G4kKuVUMFHicPqp9n89X1eg2SE34hGq7O0bw7VfearGb9z4lezkObpXTkXad7cNQyOw3k93ElipiP2xXUMbGM65osvptF/mRg2H0utmjFLuHHtUjXrnFggKZALoOBshArAqMCp/uwUmhbK8WkBvYg5E= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630644; c=relaxed/simple; bh=GdMUtH8WIg9ZYg+dAmen8rfdoxu2zuxFIPAw9B3ZDs8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=EglTdbSj6Pi+DC9HvlWO7tSbha7pwhiEW3t5s7o870M03uxj+k4rLsNcJla4PV95iwLplox2rPoDZUC8tSCFuzj2uPXcFoZyfF6ueSx+lz/kiUe0Vbv4aM7vwOTp1+Gfup8jfNyjEsBm8OkrlcElaO8aXuND4Vgl4Z5IWolUwFQ= 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=z9IoMV0S; arc=fail smtp.client-ip=40.107.208.21 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="z9IoMV0S" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bav8VlrwRdN+DwUqSnFOPBzDgiFe5GDdctAAHJnaqGJ3Q1droACACvrmhwCIUFo0kS/89Mo28vVfJguZGHKXPM/ZQXKNpnlY7KjAe9B6VI8Cxed0ckXvxF/K+mcWo8GfBiVECPDD6N9zPaeJyfQ8t259tYWdKXf746u6K9gcYyHgyBEXvjqOLLYv4kUA5YbyRoK85VMKlZswiBV1CgfHtjWfwxxG5K4ij76K4xfHTxLLRzkb7/1ibBqFzCpN60ZiwEqEtj/6tK0fqgEOplHefBVPTvdEfTeJxqTZlz0T4hcDsNc6sZk8xiF0gEDoXocSvXieF66BnnhUFoVvYGSzGA== 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=Eoa3U0HeFIQwvRWtclPcmShAKAdFiwiX1okb/u9Ugl8=; b=Ar6W+0e4HVc45aQKrDetlnHqjPR497XP07aZ06cfFP6UrP2qIROWwSToiev6gPD7Q5Ej/C+l/FqDnTGtDlWtrk8r0wXko4cs6AHL8TM6yso2HX+758gR1QWVUvD3J07ZSVsOFE5NqJEo03z+BmPeJBwh7Bm3WDn/ocpi7YI64dh3VllhTCmEIv06AcEgb6k9Cr7SwPyvK37CaOFOBJv22CtFJZ3zqgST0R6viBw5vG8LspKDOLr62pE79CNoQJSrDOP+mKXTARjSGXBmQ7PwGKMs4YW63FuY+bS88SkJ0fXXnyYd4n0m4Rebhk9CTSjYOVgSwXA3FzxlVrQoojj2Ew== 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=Eoa3U0HeFIQwvRWtclPcmShAKAdFiwiX1okb/u9Ugl8=; b=z9IoMV0Sqof/tMWe0c35eMXaE2DgQ8fFnULNzfyYwgHqiBZm44myPsEugvV9osXVf1m9oLYutVQhtj6XUm8DJyqGeQMxNJYih7CxaTIkgJut+G/rThDiy++d/mPcm0yORqB8kLdlkNZD6KcicBgI29ei4KgF2bOpx6WUk9u3MaA= Received: from CH0PR03CA0047.namprd03.prod.outlook.com (2603:10b6:610:b3::22) by MN2PR12MB4174.namprd12.prod.outlook.com (2603:10b6:208:15f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.10; Fri, 27 Mar 2026 16:57:19 +0000 Received: from DS3PEPF000099DD.namprd04.prod.outlook.com (2603:10b6:610:b3:cafe::85) by CH0PR03CA0047.outlook.office365.com (2603:10b6:610:b3::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9745.23 via Frontend Transport; Fri, 27 Mar 2026 16:57: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=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DD.mail.protection.outlook.com (10.167.17.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.21 via Frontend Transport; Fri, 27 Mar 2026 16:57:18 +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; Fri, 27 Mar 2026 11:57:18 -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 11:57:17 -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 11:57:09 -0500 Message-ID: <1515d405-62fc-4952-842f-b69e2bf192c0@amd.com> Date: Fri, 27 Mar 2026 22:27:08 +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: <20260324191337.1841376-1-jstultz@google.com> <36e96f87-a682-436e-aefc-13e2e5810019@amd.com> <20260327114844.GQ2872@noisy.programming.kicks-ass.net> <33e60181-1809-44e1-bc4c-8ac7f79d49d6@amd.com> <20260327160017.GK3738010@noisy.programming.kicks-ass.net> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260327160017.GK3738010@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: DS3PEPF000099DD:EE_|MN2PR12MB4174:EE_ X-MS-Office365-Filtering-Correlation-Id: e32ded0b-cd0b-403f-894d-08de8c21e7d0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|36860700016|82310400026|13003099007|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: /MnIZVLaXrNSs2njB5Sbwi8Ser2jr/MjVDJ5zC0VAcGr/+afiYEmllU9UrjYJkRKQspvyGAQ7qPxroBT4kjFutOuYfNfxtupOOS+jDKL0kuZDI00FGsMSEjHvea/yrEVo9KBiqXR9sTUQWdq6YNX+h/Rcc6tZHCkzuvFGjWxO6iJzuYCF5osuvPXNKluVcifs4Lor6Ewb2pjlGXr3ICZkwJOf9WXhmQj1MZoH8dc0/G6FXWTSTMmGiTfrvZO24kCMnEjNU8bckXwhQnKlRjH9QW0ox9vFxEK9p8dDEPgEiWtEUO/YAM2htW07UogK1dRRo6c3TfhdSlxqMy9cj0Jd/hzONnr+kzye4kbPMKbgYV5bixcLdMKaZuytxVbGd63Ab6us29axz3WvWErWua7xft2cOG7OY37rj+q1tFgjmdoW/RbaikQvSw4p4wfSP0mqW973loo2mAmxmao6CB/4jhq1GtYw+48TIZ7UJMt0FL96w/+JBViDlLjlseHgjS7R5lJfaMk/4XNhgE8Vqsd64dw/rPzo0F7dNWiq3gpD2UwsInzZ7PpUXIjgyHgVqNhJqkY/tXb12xtJEksAZudZyB1F12VcS/DOY4/WrZSW0HI+FKD+r12+uxRc0/4/SSqf+JkYyxM4MfFFyvMdUjLxjI+yp4rOT+BCbVbEQh701eN9FXC43LYYga6Mb+kFeL/I+tr72h77I+1c8DYMpmeo+W864mPZoXavOD3yC4skZ2N8lE8UHFjzqJVAzDKfm4KzllwGhISOY5gM3Clug9mcQ== 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)(376014)(7416014)(36860700016)(82310400026)(13003099007)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: HQWrKeBsM++oJYC6W2UeS99sRXFO01NsUb0kBrfjvPOVZb034sCS1GQ50YE/0cirUDpftc5FJ7E0oWfZdIgM3QD+5BErua2gyW7AcgmOcfgblzarmrqdeo012Q7tB+C4xLc6ZfBheSC72C7kCAVD4/McAJiNn6N8QmfWlRA0OHzVy24gwi0myZzQYCqugpYb9/fN2KdAUZv1I4IKxKulcItEIeXS3y7Obc/CimR23ls5AEeTRbvEVKqgaZkNDylRZ466m/EVpFRfg7w9Fe6qnUOEKGvWZc3cdd5cVEmqWZscmtyc5cyQn1OTid+DjSpn3BvsuwWY5vxv7ZKAAVm7ld6B/9imGVoOtq6525567bDYpZuirsXKpM8wXCOJFt1dSWURQItjEs8bv/xJL84a2CCaLbNpy2a8L6yg+PIkB2K2LRLcAaMhnogL3c/QOCGm X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2026 16:57:18.3694 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e32ded0b-cd0b-403f-894d-08de8c21e7d0 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: DS3PEPF000099DD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4174 Hello Peter, On 3/27/2026 9:30 PM, Peter Zijlstra wrote: > On Fri, Mar 27, 2026 at 07:03:19PM +0530, K Prateek Nayak wrote: >> Hello Peter, >> >> On 3/27/2026 5:18 PM, Peter Zijlstra wrote: >>> I tried to have a quick look, but I find it *very* hard to make sense of >>> the differences. >> >> Couple of concerns I had with the current approach is: >> >> 1. Why can't we simply do block_task() + wake_up_process() for return >> migration? > > So the way things are set up now, we have the blocked task 'on_rq', so > ttwu() will take ttwu_runnable() path, and we wake the task on the > 'wrong' CPU. > > At this point '->state == TASK_RUNNABLE' and schedule() will pick it and > ... we hit '->blocked_on == PROXY_WAKING', which leads to > proxy_force_return(), which does deactivate_task()+activate_task() as > per a normal migration, and then all is well. > > Right? > > You're asking why proxy_force_return() doesn't use block_task()+ttwu()? > That seems really wrong at that point -- after all: '->state == > TASK_RUNNABLE'. > > Or; are you asking why we don't block_task() at the point where we set > '->blocked_on = PROXY_WAKING'? And then let ttwu() sort things out? > > I suspect the latter is really hard to do vs lock ordering, but I've not > thought it through. So taking a step back, this is what we have today (at least the common scenario): CPU0 (donor - A) CPU1 (owner - B) ================ ================ mutex_lock() __set_current_state(TASK_INTERRUPTIBLE) __set_task_blocked_on(M) schedule() /* Retained for proxy */ proxy_migrate_task() ==================================> /* Migrates to CPU1 */ ... send_sig(B) signal_wake_up_state() wake_up_state() try_to_wake_up() ttwu_runnable() ttwu_do_wakeup() =============> /* A->__state = TASK_RUNNING */ /* * After this point ttwu_state_match() * will fail for A so a mutex_unlock() * will have to go through __schedule() * for return migration. */ __schedule() find_proxy_task() /* Scenario 1 - B sleeps */ __clear_task_blocked_on() proxy_deactivate(A) /* A->__state == TASK_RUNNING */ /* fallthrough */ /* Scenario 2 - return migration after unlock() */ __clear_task_blocked_on() /* * At this point proxy stops. * Much later after signal. */ proxy_force_return() schedule() <================================== signal_pending_state() clear_task_blocked_on() __set_current_state(TASK_RUNNING) ... /* return with -EINR */ Basically, a blocked donor has to wait for a mutex_unlock() before it can go process the signal and bail out on the mutex_lock_interruptible() which seems counter productive - but it is still okay from correctness perspective. > > One thing you *can* do it frob ttwu_runnable() to 'refuse' to wake the > task, and then it goes into the normal path and will do the migration. > I've done things like that before. > > Does that fix all the return-migration cases? Yes it does! If we handle the return via ttwu_runnable(), which is what proxy_needs_return() in the next chunk of changes aims to do and we can build the invariant that TASK_RUNNING + task_is_blocked() is an illegal state outside of __schedule() which works well with ttwu_state_match(). > >> 2. Why does proxy_needs_return() (this comes later in John's tree but I >> moved it up ahead) need the proxy_task_runnable_but_waking() override >> of the ttwu_state_mach() machinery? >> (https://github.com/johnstultz-work/linux-dev/commit/28ad4d3fa847b90713ca18a623d1ee7f73b648d9) > > Since it comes later, I've not seen it and not given it thought ;-) > > (I mean, I've probably seen it at some point, but being the gold-fish > that I am, I have no recollection, so I might as well not have seen it). > > A brief look now makes me confused. The comment fails to describe how > that situation could ever come to pass. That is a signal delivery happening before unlock which will force TASK_RUNNING but since we are waiting on an unlock, the wakeup from unlock will see TASK_RUNNING + PROXY_WAKING. We then later force it on the ttwu path to do return via ttwu_runnable(). > >> 3. How can proxy_deactivate() see a TASK_RUNNING for blocked donor? > > I was looking at that.. I'm not sure. I mean, having the clause doesn't > hurt, but yeah, dunno. Outlined in that flow above - Scenario 1. > > >> Speaking of that commit, I would like you or Juri to confirm if it is >> okay to set a throttled deadline task as rq->donor for a while until it >> hits resched. > > I think that should be okay. Good to know! Are you planning to push out the changes to queue? I can send an RFC with the patches from my tree on top and we can perhaps discuss it piecewise next week. Then we can decide if we want those changes or not ;-) -- Thanks and Regards, Prateek