From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011066.outbound.protection.outlook.com [52.101.52.66]) (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 C18BD1B4257 for ; Tue, 18 Nov 2025 05:09:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.66 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763442552; cv=fail; b=czHuZ2Ah5/5v5RfaFIfQenwsBOVX1dly2DRfyXuGRW56ID/3hOghi2d/A+XXMFmIsy9rlVva+BGNOpRC31W6+pkIrI4b6L987lPklWwCIanlBKJ3G32RxK+FgiL/YcuvtWxMwXX5R9p99TESWH3MqIZM/sW1iM43PEmKunlRW04= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763442552; c=relaxed/simple; bh=ESAuwLjgx8ff0DO2Ls7/jqbjK+7WGpds1MhtrHkK2mY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=DNu9acQCifjo3owBJYO5VWgSNPnqASP8giuud/28NR7UsYEBnT/r3YUvrMCxboqau6c+9xY9V2bNnZviAPw1fSaDW7m8bmWLkhCuTaBJJiu41BQddg07N75USX7zw4sg4KEQV85i67VByIpDsGMDp+q120rp1s6OlDWPVn5Pwvw= 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=V3LcXA//; arc=fail smtp.client-ip=52.101.52.66 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="V3LcXA//" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dZ1DCq4NUeiNqtQmGUj+Le8cipIIn1Arh1jLSemAphBAkp/r+ta0uL34uTOqcfsQ1jpmxeGBO+5Qh7APa+utDPl/OU6d/zrHqRUH/TY0Rgas7b3Ujfe+z+FHDiWp7T2fbsMPNci7sN+ZPhqx0ezUjSIYqBl4u/J27jwhQWStb/0JugRdUdaWmMVhl2W9RyB9vX9SLBMjVKbqZ1XhS+djlQfuaiJCJdEsj7szj7zJFK9+VkMyRiZ1Y2aT9bwSRwOjJrA5vVqPtg3uvEtH0SvkD/XVS3sibXmUbb22rYtjev9v3rIKLIdNg0KGVf7QaZQ6r9svXalK7SW1xCtPy63pjQ== 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=+iW9IOPkH06mCjO2iKKttrjHeJkJ1mjimjC8htwnT0o=; b=YEX8JEn6psZX5CKE75wEe2kMbaP2MUsq4wU8LJvhgZVOfKzFhs8azG4BN52tNlrmGATA0EZoV/OG0Dg9PjbX5wU14cEQ0ME8JTGN32awQBNATEpewCZTeatRMnd4N7np6Hxnt2KZRfY17zOeD5e+H3vGyNbi2jBh8J9h0jinF4vh4y+WSF2ImYKd+G8kHe+3qS6dbdeLpo4i0xNS0GPyl0wzX9nK61DiEqOvebWXU6kPDEG3NuIhu1DF4XQsSxooKYyPj2Wii7dIlK8te9M782NeNJNSudXR5EZv7yG5OLilH4LlvMPXrUMtlTf/5xWtcJJ/0e3CqscBEr/zLSYgeQ== 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=+iW9IOPkH06mCjO2iKKttrjHeJkJ1mjimjC8htwnT0o=; b=V3LcXA//drjs+cbwmc3bngFVZVKDI156he7xEC2dNST/ISohPrHz0pbbSUYjviVJtJgcEr4aadz4PeMYqeaVo6iG4IhieHewUwpUjePdMimAWG5dtZMuPjgpq0iPiTmYs3pnGKXVFH0DaG8jISyk/jZ7cSHtIkmMTuq5/BIcnDM= Received: from LV3P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::29) by DS0PR12MB7875.namprd12.prod.outlook.com (2603:10b6:8:14d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9320.21; Tue, 18 Nov 2025 05:09:03 +0000 Received: from BN2PEPF000044A2.namprd02.prod.outlook.com (2603:10b6:408:234:cafe::20) by LV3P220CA0007.outlook.office365.com (2603:10b6:408:234::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9320.22 via Frontend Transport; Tue, 18 Nov 2025 05:09:00 +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 BN2PEPF000044A2.mail.protection.outlook.com (10.167.243.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9343.9 via Frontend Transport; Tue, 18 Nov 2025 05:09:03 +0000 Received: from satlexmb07.amd.com (10.181.42.216) 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, 17 Nov 2025 21:09:02 -0800 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; Mon, 17 Nov 2025 21:08:59 -0800 Message-ID: Date: Tue, 18 Nov 2025 10:38:52 +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: [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution To: John Stultz CC: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Johannes Weiner , Suren Baghdasaryan , , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider References: <20251117185550.365156-1-kprateek.nayak@amd.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: BN2PEPF000044A2:EE_|DS0PR12MB7875:EE_ X-MS-Office365-Filtering-Correlation-Id: e066c802-fb8d-4703-c297-08de26609787 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|7416014|1800799024|36860700013|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Vmt0T2dGYWNHeVdVakg3TGtNR01GY0Q0ZVpIUnJGejJ5YWNYc2x2VHFlbGVs?= =?utf-8?B?dnJObzh3TWdUV1orc0FOa2o0a0FBTzB3azhXOFpzUjdLZ3VWaTRlTDdSbXQy?= =?utf-8?B?aWxPVlZNbFFTa2pJMUNNNHkvbCtvYk92bFI3cHN2N3VLZEdSS29oQ1NUL01W?= =?utf-8?B?UkoyL25haGVHRFlBakw5TGo0U0g1aEd6OTYrWVpDNGdSVUF4aHBpV0QydHpQ?= =?utf-8?B?UHlNL1VodnRXMGFWN2Z1RnhTN25EN3pMYmNUN2VtUkNuaFd1dUJsaDMrbTE4?= =?utf-8?B?Rm85ek1Bd1VidzVHK0RKRGsxeXgyeHNJY1hUNlErREJmdTNDbVRiOElvVnQz?= =?utf-8?B?NHFjSWlrVTJyMFJSU2M1b0NYdDJUb1lSd3gvRDZzSDNYdWpGQWhSVHRmdWpX?= =?utf-8?B?c042VWc5bTBlM2t0R3FHM1N3WitVZEx6YWZqQ1p2YUVLSXJXTUZkWWg0YTJ5?= =?utf-8?B?bVhWa0VYUlhLU09ucURsai85TTBYTmdoajlUNTM2TnpPVmc1Q0lKSFZjQ0xa?= =?utf-8?B?VmFITmtXOXV5ZEJVZHlZTFhBcFVUS3c0RkxrQkJuSkRZTG40YUdON0NPNWp2?= =?utf-8?B?RXF3Z21LVitIbmlCYXA1eXYvZXBYQUZMVUNrTFZJUWMwMTAvMGVrK0IxaTJ1?= =?utf-8?B?MXBhcXBXS0NoWittSjNkSUEwZkxtbUlPeG9vRXI4Y05yVWlxNFNCVjFUMjNp?= =?utf-8?B?bWRDenNDaWFNNWJ5dC9VWGErbnhJdTQ4ZGVjVWozV3lpeFlIWVdxblZhWERU?= =?utf-8?B?QkRCZkZGcHNNaSsrWEJzZUFNbmZiakp4Z1M2LzY0a1ZXREVyK01DSkRWZ3cv?= =?utf-8?B?bXMyQkZsRm4zczQvcVo3em5pdFJ6bmUxSWFBNTN4Z1BlUGtHRTFRTzhadnND?= =?utf-8?B?SWdWaHV3WWNPM0JBWmM5b3BTYko1UGt2VXAxYS9HenZ2cjNOaWhPM044bnk4?= =?utf-8?B?OWtxMzNiWVBNQnRLL3hiRUdDRVFqRW1MMHgvV1ViSUk0MWRxSis5WXB5VDZs?= =?utf-8?B?S29tdS9DV1hKbG5SckFGVTJoWjlkWm9ZNExXSWFLNDRCS3YzWkVWSzllVG5o?= =?utf-8?B?UDM4Q09DQ2luOXE1bnVCWmJGNTFEK3gxTTFVTmxnZlhKS1hrT3pRVWRaWklD?= =?utf-8?B?aXh6NXJlV3F1eGJDRFVYV0kxOFptaEJDNElwUy9GSkduYnVTY2JuUEVJM1Z6?= =?utf-8?B?N0ptSEZBTzYyYlp4bFN6ZlVQVkQ1TzFmbnZOWGV6ajF2MitWSTljSkd4S1lV?= =?utf-8?B?bVlKMGZBbzBMR0FQU1AvcjNMZFN4OEpMTGJPb1p5ZlNOekF5NnhDMHZ1WEZz?= =?utf-8?B?WDF0WGc1ajFnOVY2b1NHQ2d6T3VsbVZMZTJaU3NPTThiSFdNNzEwOUZ1dVo1?= =?utf-8?B?ZzVNUHg1eGtJVWlPUEFvY3VGTVllazg2NWFaNHlDZE93U1VFMmxYaFFaZEUz?= =?utf-8?B?ekw0dE9ZaDU5UFNFNzI3RWFkSEVGS0FDcXI1c25sVVhFRGZ4Wk5xNmZwYlFj?= =?utf-8?B?V3c0WGQ0elB4WUxabDFoR2R6a2N0RWxuMjgzaFMyL3V1c1ZZb1BZQkduQTRJ?= =?utf-8?B?ZTBIVHNibnZwMnluSDRFbU5HYzNiWDloK01UbmJ6d1Q0WTQ3MWN1bnJkNTZL?= =?utf-8?B?N2ZmK1hNU1pqZENwcTYvc2VONkdMQWgwUmx5WXo4UmtndTBOdUJzSFZ1cmps?= =?utf-8?B?MG42MHQrTWRYQlFKUnhNS1haYkJlanlTYm9WZ2hxYkVmU0FQQ1QvSUZ5SDF4?= =?utf-8?B?aHh1ajU3S004QXdmdDMzaExiZkdYRnpEdEVOZUcvM3NsNloyUE9oWWoxTkFY?= =?utf-8?B?WmU4ZnROeHA0eVpYR2VBYTJBaW9aN0ZFV3pGY3hFMHhpY0xNSVdvM1RIRzhV?= =?utf-8?B?Qm0vQTFmdVVvWDcvc3FiS0d3RXZyRnBiYlNaUFdqWnozNkhnckFRb2lxSU5I?= =?utf-8?B?LzJiSWF2WVhkWXUybC95Z1dJT0wyTDhpdEVSQllMTDluQlV5cjlRTmNMYTF2?= =?utf-8?B?c0xZU3ZJVjNYZ2RPNlIvZ3l2eWsrOHgvaTh0UlFaa2RKSXVrTHQxSXh5Nkw3?= =?utf-8?B?YkV4ejVua1dnSUo2NVA5UGliamNDRnhvYmN1aHJmZUUySVYyRGJkdExtSFd2?= =?utf-8?Q?QCMc=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(7416014)(1800799024)(36860700013)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2025 05:09:03.3765 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e066c802-fb8d-4703-c297-08de26609787 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: BN2PEPF000044A2.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7875 Hello John, On 11/18/2025 9:56 AM, John Stultz wrote: > On Mon, Nov 17, 2025 at 5:39 PM K Prateek Nayak wrote: >> On 11/18/2025 6:15 AM, John Stultz wrote: >>> I'm still getting my head around the description above (its been >>> awhile since I last looked at the PSI code), but early on I often hit >>> PSI splats, and I thought I had addressed it with the patch here: >>> https://github.com/johnstultz-work/linux-dev/commit/f60923a6176b3778a8fc9b9b0bbe4953153ce565 >> >> Oooo! Let me go test that. Seems like that solution works too on top of current tip:sched/core. I think you can send it out as a standalone patch for inclusion while we hash out the donor migration bits (and blocked owner, and rwsem!). >> >>> >>> And with that I've not run across any warnings since. >>> >>> Now, I hadn't tripped over the issue recently with the subset of the >>> full series I've been pushing upstream, and as I most easily ran into >>> it with the sleeping owner enqueuing feature I was holding the fix >>> back for those changes. But I realize unfortunately CONFIG_PSI at some >>> point got disabled in my test defconfig, so I've not had the >>> opportunity to trip it, and sure enough I can trivially see it booting >>> with the current upstream code. >> >> I hit this on tip:sched/core when looking at the recent sched_yield() >> changes. Maybe the "blocked_on" serialization with the proxy migration >> will make this all go away :) >> >>> >>> Applying that fix does seem to avoid the warnings in my trivial >>> testing, but again I've not dug through the logic in awhile, so you >>> may have a better sense of the inadequacies of that fix. >>> >>> If it looks reasonable to you, I'll rework the commit message so it >>> isn't so focused on the sleeping-owner-enquing case and submit it. >> >> That would be great! And it seems to be a lot more simpler than the >> the stuff I'm trying to do. I'll give it a spin and get back to you. >> Thank you again for pointing to the fix. >> >>> >>> I'll have to spend some time here looking more at your proposed >>> solution. On the initial glance, I do fret a little with the >>> task->sched_proxy bit overlapping a bit in meaning with the >>> task->blocked_on value. >> >> Ack! I'm pretty sure with the blocked_on locking we'll not have these >> "interesting" situations but I posted the RFC out just in case we >> needed something in the interim but turns out its a solved problem :) >> >> On last thing, it'll be good to get some clarification on how to treat >> the blocked tasks retained on the runqueue for PSI - quick look at your >> fix suggests we still consider them runnable (TSK_RUNNING) from PSI >> standpoint - is this ideal or should PSI consider these tasks blocked? > > So my default way of thinking about mutex-blocked tasks with proxy is > that they are equivalent to runnable. They can be selected by > pick_next_task(), and they are charged for the time they donate to the > lock-owner that runs as the proxy. > To conceptualize things with ProxyExec, I often imagine the > mutex-blocked task as being in "optimistic spin" mode waiting for the > mutex, where we'd just run the task and let it spin, instead of > blocking the task (when the lock owner isn't already running). Then we > just have the optimization of instead of just wasting time spinning, > we run the lock owner to release the lock. I think I can see it now. I generally considered them the other way around as blocked tasks retained just for the vruntime context. I'll try changing my perspective to match yours when looking at proxy :) As for the fix in your tree, feel free to include: Tested-by: K Prateek Nayak > > So, I need to further refresh myself with more of the subtleties of > PSI, but to me considering it TSK_RUNNING seems intuitive. > > There are maybe some transient cases, like where the blocked task is > on one RQ, and the lock holder is on another, and thus until the > blocked task is selected (and then proxy-migrated to boost the task on > the other cpu), where if it were very far back in the runqueue it > could be contributing what could be seen as "false pressure" on that > RQ. So maybe I need to think a bit more about that. But it still is a > task that wants to run to boost the lock owner, so I'm not sure how > different it is in the PSI view compared to transient runqueue > imbalances. I think Johannes has a better understanding of how these signals are used in the field so I'll defer to him. -- Thanks and Regards, Prateek