From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011070.outbound.protection.outlook.com [52.101.52.70]) (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 7B1F230F7EA for ; Fri, 27 Mar 2026 13:33:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.70 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774618419; cv=fail; b=GR+U1zc/4wGg8ZQGaqvVl9owSulpH8YgcUtC/5QKKdQRe5olxkSpKgQ7/CFMknGR9yJD+9Y2Os02B3sML9j1+1BfbspINbG+jRu1WwFNfCuMnT5Trnvj5z1mwVeZn/ZqVACLmgAI9dbQmQ4jxfDwGxCsDceWFd/o5Vei22WyX8g= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774618419; c=relaxed/simple; bh=jhNrDM50ViZyOxlwixsvaVUlNUAqVKXHOEkHP9u8t64=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=kDD90A6TczkRse192VvDMaSDTGGjrw0IaPNuQFwpDw/WfN9VZRDu68XD5GXQbenBGmx1+C/aCBPPDUhvsCgPS/LddcoPLo3kiIj4UKwqSfKIsruswRGQQrE7DnVWX2c3pnakfmy2PIXo41SSJMBjDHQdlHQAbh/+rJrk+fCyybs= 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=mtfcq2Qx; arc=fail smtp.client-ip=52.101.52.70 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="mtfcq2Qx" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PA0WZQmhgcNZp5K538kkWEAt/CXrFizofV26v6OHs9dq5k/YNSL5cSGdg77R89flan4JCyG7zygBjDMDnUM4CXI4BWW7BA9D35E5Y5gXMmlA33vIyQxDgeCOCEXu3xEVbhdbEpYZqzaMcKFAr4wQMwFUnthkb6Jp8qLrkTM/Xig/kGQCFHytTSMigymM7ymknCrhqypHvfzWubNbrtuSzlf8MIXd2PRvy5zBjxY7RJEmSrB+tAGB6NU6lGDm2BDxFGpKQ8PY/UMhdwzepDdUufOQKcarMmvpuIHZRi2LwI9iw9CrbpZ7O4BKZJcWUpQ0HIvtpfo/DTszXTeRb+BAxw== 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=2vC9Jv8qF+O4imSVAIp8xUXFSJwqdQpL9bg29i1Gi9o=; b=dUTaJCo+FkF/7oHe6XK3F4qySE7JpmccxJsTy3JpaqQJr0n0DdRgvu2iu7f/irbIWiMCRQF5zXSgiEF2tuEejeZHHdX9Wo0pVMfUY060q8YOwxX0ls6d7Z4V3DbaZm1oeK7THDHYa5tNxGdDEdg+9dfnMxlkKxPYqxp82QgxT7WQ75BrINz9NgJpxuAnpB7Vx2AhpL07R6tLd136ukfuOXd8g1kz9Hmbki+ssqoBtXgt75Ta26mQLgWQIXcGecHz/Ry8MdcJ2K7L56O+kFnHGrbulfozFgAGBTOA1ytu0qFg0jXDQa2k7S0rR+vuR5kVOWYVbf4qKcV4yUbxl6O4mw== 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=2vC9Jv8qF+O4imSVAIp8xUXFSJwqdQpL9bg29i1Gi9o=; b=mtfcq2QxgzzdP7BulzLlauUh/nAjzE8JZRWJ/b0loqKj9wwd51BXz3eHa5hzLjeK9E03PM+2sxqR4dTSjlDVwngbAWbrlkza8D0OrmPKm6bwg8y0OJn35T2d1izMmzBKgPNlff7pAWgZecc61BD+bb1ilVRO7ziN5Ufr24vIDXk= Received: from BY5PR20CA0030.namprd20.prod.outlook.com (2603:10b6:a03:1f4::43) by DS4PR12MB999099.namprd12.prod.outlook.com (2603:10b6:8:2fd::21) 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 13:33:34 +0000 Received: from CO1PEPF00012E83.namprd03.prod.outlook.com (2603:10b6:a03:1f4:cafe::1f) by BY5PR20CA0030.outlook.office365.com (2603:10b6:a03:1f4::43) 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 13:33:33 +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 CO1PEPF00012E83.mail.protection.outlook.com (10.167.249.58) 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 13:33:33 +0000 Received: from satlexmb08.amd.com (10.181.42.217) 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 08:33:32 -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 08:33:25 -0500 Message-ID: <33e60181-1809-44e1-bc4c-8ac7f79d49d6@amd.com> Date: Fri, 27 Mar 2026 19:03:19 +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> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260327114844.GQ2872@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: CO1PEPF00012E83:EE_|DS4PR12MB999099:EE_ X-MS-Office365-Filtering-Correlation-Id: 18fddf06-6f3b-4cf5-0955-08de8c05712b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|7416014|36860700016|13003099007|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 5sdxhayOorQA6DX4BRbmhIVdRNAPNWKGWLBQmSqplTUa7doMP5z9mtLf+Qs65fWjpMMI4aKZ9HysbvHnr11pVf6anQPFUz/oTc3Mpk9SMq9VzCPQMBF7811k3giKcW53Yiec1u2V82V2TbIdYJeQAsl/TJyXc98e8wpo1OZEMBvG7jad7mQ7z/NS+F+v9TwGUgzsx6wMxYGkJUtd7bbCcPLs09MfRDCAtkbO12qAtL7lhrQhc1mK8FFWLKlw9pWvnGcmcelM/Q3d9mI4gh4pAlaBeCQJR0WCUb+LWHxEDaHdETVGoWphkPNsMNQi8JB5HUBziOIN5chPoOA0gRUk7RFyf4Umm5G7/Df5K0RY8+Zd23Nm4hilJySIRdt5SVzLDaMKd9ILDrebY3SnluTADFN6/AHOQeV14Jk7ccYzBMs/zVPjpRcFhTmtu50gbXeKPG4utZGcHuGpEKjqKDhwiolZwnvE3hJNiImSffjU3nPn+rRZ1KFzUo/aWryo0cognKNUHpva7wGqoube94m2BDESwcMIZR/ltKUq962Ic5ePFiVZztq6VQGDuKlATjDEAcXu6N6uut2Tb8IyiqBnh/Yp9RdTgQv9UNq0TlmRIqbl60A6tbZtK9UxUWxmWCM7kF+sfxViC3EqGJracqyTGgN+pZ7hd2ZnpW24Se/766sV+QNKzqaG9P/jj36bPQbhs+CVRPGUY4qR6D8ls9LDVDliNxHXWaGtks1RnVfeeI4= 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)(82310400026)(1800799024)(376014)(7416014)(36860700016)(13003099007)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nu06AFCXCcLJ2H1ENHqy7sGftGyPII2P3enSDTTxi/fnuZH9sIx7z8pkMncKAPo/eCGpWdQ0PvlhVW6J+PCjze6s2BmbWgmLMDxqB5uhiakLLwhkJcjoQrrRBh6c9LPIcPJd9WkvE/mGzR1jM08IWhS0dvpdY28Ey/5dyjE0sKcr11DDRXAHuxL+bQkJEanl0RoiUcEzUfRDPNsPiH8cxQ2JgATrnnx3Yixu8+wZAHnAWNyrCI2LkU8cpGzzCa16KHz8VcIEoNtJABn+GOigy2A3Ra1f8m91Sgo24zw4kkcuo2Q1CzQmi1qcd8qKPhpn8gqgwRhL8zm0+XlYBo2w4jn3c/i+vpNGLKsDQITPOMAx9IWYMnNwuC/Cu7GhKQUG0LuwcnwaUeby3HsXB5yIgS7YygNaZx/GawVNCm6b3FuQDlAm8yjX4J2ie1ms0ctg X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2026 13:33:33.3436 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 18fddf06-6f3b-4cf5-0955-08de8c05712b 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: CO1PEPF00012E83.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB999099 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? 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) 3. How can proxy_deactivate() see a TASK_RUNNING for blocked donor? So I went back after my discussion with John at LPC to see if the ttwu_state_match() stuff can be left alone and I sent out that incomprehensible diff on v24. Then I put a tree where my mouth is to give better rationale behind each small hunk that was mostly in my head until then. Voila, another (slightly less) incomprehensible set of bite sized changes :-) > > Anyway, this: > >> fd60c48f7b71 sched: Avoid donor->sched_class->yield_task() null traversal > > That seems *very* dodgy indeed. Exposing idle as the donor seems ... wrong? That should get fixed by https://github.com/kudureranganath/linux/commit/82a29c2ecd4b5f8eb082bb6a4a647aa16a2850be John has mentioned hitting some warnings a while back from that https://lore.kernel.org/lkml/f5bc87a7-390f-4e68-95b0-10cab2b92caf@amd.com/ Since v26 does proxy_resched_idle() before doing proxy_release_rq_lock() in proxy_force_return(), that shouldn't be a problem. 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. > > > Anyway, you seem to want to drive the return migration from the regular > wakeup path and I don't mind doing that, provided it isn't horrible. But > we can do this on top of these patches, right? > > That is, I'm thinking of taking these patches, they're in reasonable > shape, and John deserves a little progress :-) > > I did find myself liking the below a little better, but I'll just sneak > that in. So John originally had that and then I saw Dan's comment in cleanup.h that reads: Lastly, given that the benefit of cleanup helpers is removal of "goto", and that the "goto" statement can jump between scopes, the expectation is that usage of "goto" and cleanup helpers is never mixed in the same function. I.e. for a given routine, convert all resources that need a "goto" cleanup to scope-based cleanup, or convert none of them. which can either be interpreted as "Don't do it unless you know what you are doing" or "There is at least one compiler that will get a goto + cleanup guard wrong" and to err on side of caution, I suggested we do break + enums. If there are no concerns, then the suggested diff is indeed much better. -- Thanks and Regards, Prateek