From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azon11010066.outbound.protection.outlook.com [52.101.56.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 3A70C347513 for ; Tue, 3 Mar 2026 05:59:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.56.66 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772517596; cv=fail; b=dpPHvkPKLzDLOsSu3P5ap8sfksIgiRYOC83VeELg7HeoHnfTczbnkmUls/hYUTXfb3rA1lEJY0KmHRsTtI+MiseC3ZcQAS/rK+jkTA4y7OZj56Uzk2mbIBVHliV0ZKcpr5+SDSv6dw5lLixpeZMv4zQdrLz/i7h4/oBnf5EXhmk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772517596; c=relaxed/simple; bh=fMXoAOSK/G1tPImg/B9qgAkQ2t47xktivRwQ5rQEpf8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=KIVh8dVN8nI96qITDuoylBdi6IaMr7Tt0sEWHFgFNnIA0E1qyncRl8WE72Ayeii+LzI+VgW58emx73SdHWRL0iDyeQr8gmQdeI1LKIb6Fgqa+DMEWv18AsxH47/FOHHa2FRU87wtfWh0i1rHc06xrEb0Um5Vkimhd+Cv8Kvb+8Y= 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=ppqfosnG; arc=fail smtp.client-ip=52.101.56.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="ppqfosnG" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t28COL9pE+p1nDDGUMyFXmv2Q7VbyqbcPiJjh6AufrkgkPltL7jfgYgLK/0iKYkOqYXH5bD6CrAV/evSNs9OY9ZIB5UP1FmgR5rYYvSSmXZPmhlBR66853/rvvqHwRDLeAkFMdcuzh0XlgJBeNmm3GwXh/TE0SZBT/P6HmkBOx/uWIQ+YeHglhUT0Ggc60HoVd76oqzGlwcztEjdaTTv14PKeG1n9IAH4bPwdtuGrssCIoWZibkQd7/dKXoU3G24qYi9ARlHGMEORzTGfXYgDNt+e6Lbas/+EDInPr3V9TF15RUxUK1lc1UUbJkuGiNhuZynP80QUFA33hZG0bOXzQ== 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=1YT7SPpB0yD9hg7d2macoV6/qlfPV+ZrbV28bPa69p4=; b=UstZtT4fnLTaqxLKfC2U+Jgtr2pFM/2vjnxZtPqCT13MKZvkyNHsXF9nxXObManDkhbTF7IIHMRFrDnr3/KcopeJ83wdLRIVeHJj98mTGaUR4uqprMICfTL8psLuFuBe4usEaui0KtqzPxg4sQhpyFCjDkaMwQo2L5KYj4U5soExDipuuTWgMJfaIAXKaF28T+EVOcfwVOjyPxFa1BmfiW5EgtfnNGveGKf2puZDBQNohoMxOjKo/Q0NAlyfvng+OIVF/mNKM03ZcbUZTuMeHt5wNRQO+/WJaqKy7RL/x+8iUK8AmejJvB5EaYYMqH6uQy4qSDsKzSUBQb/sexTnHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=gmail.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=1YT7SPpB0yD9hg7d2macoV6/qlfPV+ZrbV28bPa69p4=; b=ppqfosnGcglMXJlP6NE5mz14QmqCe1jLJ39g/1ot1cMIHdAuVcf0Ow3cCWaQVC+BNH+CrdyE7VuWTsmjtuwIWkLHjsE9qwTH/zurH7XdNkoeJD/+FyyNymk+Q8HClzp38qXnnHnZExt3eQzpDOg2jP+bZdgnghJv6zzZjEWiMTw= Received: from BY1P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::9) by CH3PR12MB7690.namprd12.prod.outlook.com (2603:10b6:610:14e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 05:59:49 +0000 Received: from SJ5PEPF000001CE.namprd05.prod.outlook.com (2603:10b6:a03:5c3:cafe::54) by BY1P220CA0024.outlook.office365.com (2603:10b6:a03:5c3::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.22 via Frontend Transport; Tue, 3 Mar 2026 05:59:49 +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 SJ5PEPF000001CE.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Tue, 3 Mar 2026 05:59:49 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 2 Mar 2026 23:59:48 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Mar 2026 23:59:48 -0600 Received: from [10.136.33.80] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Mon, 2 Mar 2026 23:59:45 -0600 Message-ID: Date: Tue, 3 Mar 2026 11:29:39 +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] sched/proxy_exec: Handle sched_delayed owner in find_proxy_task() To: , , John Stultz CC: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , "Mel Gorman" , Valentin Schneider , zhidao su References: <20260302101235.3988601-1-soolaugust@gmail.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260302101235.3988601-1-soolaugust@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: kprateek.nayak@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CE:EE_|CH3PR12MB7690:EE_ X-MS-Office365-Filtering-Correlation-Id: 813e0a99-2439-41b6-8afd-08de78ea1468 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|7416014|376014|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: uTbI89lp137G9cI6tOiCnOjUtzT4xobD2JcNCME9kwWSRDMx0SXkHj5XFVf++dqR9mjBU8RelLcOw0PSHkOgZQKFAUzxCoAiitFyGiNHGnAxgqMT9Ze0RWCBiuqQKMG02SPVjUPKzFAQZUYK6C7Nit2B+UfN6W0UDgjrkbcHKhm/Umu4zIBqCqivCYL0ynA+HzMg/JxsLHJ0VIfpHSTkNQ8ahWII+2Urf/qT94TKD4zc8oDEd3PiuLu7eivPNcIR4BSES8scI/zXIe/cnBfrnTYzXMx4XCnPnVrDomlqgJqrlRjkRIWdNjTYjtzNJL8vWq8AWsKKaoporyHhtghJsFYkw4QpEKQaDVw7BdP31ViKL5MtH+Q1B37Uwoyr+zbPZQ9Yqc21ODioYbeTtwsQB5d6iA2vuOFCmPVrGwiBmEJvWwXJGi+HyZ0YA2q8w8MCjbIfrY2Uuut9Z/HnSWrPCrtZ171bdJjmTmTxsC9rdujUJYXiy92BXmpv12wowHkg9v3WD8kcVkQZP8OtteIcvx+ne5fu5X+dbKwl2URbnfmSmyHOSeG1lCmV4WWcOp9LSVmeJ/ZRumlZSj1PZHj1A3znv0ECH2VaWkfSkFrlpi6XwkDUFoShQGPdpWKoJ2e2Vla7/E6k9M9XsdjnmofZz+S8/EUmo5FhM+LVSb6388xPpnJo4QTcQyO2Z603mYPHf8U9nb1WZaVsGUOer+FkCYCGQszb23v8dLh4P6h7j/rMsSoy5DaPtXaKMuvX5mYdttxO1ctXArIOYhHOcEKi3BeU6cEjs5Fsv1T8M52sKr3IWVUqWbvq4+I2z8/LE9MxaNvE30Jw4pbehQEFE5F5WbwcY0WSJplr2hRpsIFeqwU= 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)(82310400026)(1800799024)(7416014)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: lK8IanPdeS2FVoGtZO0F4LNimdjj76mAvbtgk85C8Wi2lYa83i6nqSjZq+FmdIbTCh7nq1QMCk3CDsAf4gtL1URnu3exK7ht0U8vuTiUZdAaJ5YK06QFL92BYewG+VSd86XjnuRgUb5QylDtW5+UT9ETNBjkHW8u70Vu7S8Jm0u0ZfRswbxS55mAyXnocNFSy5+qEygk0fAeN913IUS+QC3RUO03Vhk49T/QlSf6JIoPN+K9V64ZNNBD7b4QzhclrcRCux1/g5KJd165oCjf2duwUtZvCbmQ6fOE8rLgv5lvlVcEYLC6Xma8V+tHTz4dPjy0MUz7Gs2rx7/0kHqrHu5FsToucSYk0ZVboxGjMraPLdjgFza5CZlY+MVw6vbIXUwA5gYCPhVXsRYwuqYEl4hNeoCN46zhqHM5oGcAa397g3DL3fHPNkR2wzSLG1SV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 05:59:49.1925 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 813e0a99-2439-41b6-8afd-08de78ea1468 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: SJ5PEPF000001CE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7690 (+ John) Hello Zhidao, On 3/2/2026 3:42 PM, soolaugust@gmail.com wrote: > From: zhidao su > > The blocked-owner check at the top of the inner loop unconditionally > lumps two distinct states into one: > > 1. !on_rq -- the owner has fully left the runqueue; PE cannot > proceed and proxy_deactivate() is the right action. > 2. sched_delayed -- EEVDF deferred-dequeue: the owner called schedule() > but was kept physically in the RB-tree because its > lag was still positive (entity_eligible() == true). > > Case 2 is transient. The owner will resolve to one of two outcomes: > > * A wakeup arrives --> sched_delayed cleared, on_rq stays 1, > owner eligible for PE on the next cycle. > * Dequeue completes --> on_rq drops to 0, caught by case 1 above. > > Calling proxy_deactivate() in case 2 is unnecessarily aggressive: it > removes the high-priority donor from the runqueue and clears its > blocked_on, discarding valid PE state for a single missed cycle. These bits are still in development and will get sorted later in the series with the blocked owner handling. See https://github.com/johnstultz-work/linux-dev/commit/e39257424cf2edb17b6be9be3cd50796d6650b1b > > A task that enters the mutex slowpath sets blocked_on before calling > schedule(), and try_to_block_task() is only reached via the explicit > DEQUEUE_DELAYED path -- not the sched_delayed shortcut. Therefore a > sched_delayed owner never has blocked_on set and the chain cannot be > followed further regardless. > > Split the check: keep proxy_deactivate() for !on_rq, and switch to > proxy_resched_idle() for sched_delayed. This mirrors the existing > handling of task_on_rq_migrating() owners (see proxy_resched_idle() > call below), which also uses a yield-to-idle to handle a transient > per-owner condition without disturbing the donor. Just switching to idle will not alter the EEVDF state and the pick will still converge on the same task whose owner will still be delayed. Until a wakeup or a full dequeue (and the owner could also be on a remote CPU at this point), the pick would just be spinning in __schedule(), continuously calling proxy_resched_idle() since nothing has changed in the wait chain of this CPU no? next = pick_next_task(); /* Gets a blocked donor */ if (task_is_blocked(next)) find_proxy_task(rq, next) ... if (owner->se.sched_delayed) /* Finds a delayed owner. */ next = proxy_resched_idle(rq) /* * Switched to rq->idle with NEED_RESCHED set. * Comes back into __schedule(). */ next = pick_next_task(); if (task_is_blocked(next)) /* Same blocked task! */ find_proxy_task(rq, next) ... if (owner->se.sched_delayed) /* Owner still delayed */ next = proxy_resched_idle(rq) /* Again switched to idle. */ ... And the cycle repeats with preemption disabled !!! This is terrible since blocked owner can be delayed on a busy runqueue for more than a few tick - sure it is a transient state but it can last for a while depending on the state of the cfs_rq where it is delayed, up to few 10s of milliseconds in a practical worst case scenario. > > Signed-off-by: zhidao su > --- > kernel/sched/core.c | 25 +++++++++++++++++++++++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index b7f77c165a6..dc9f17b35e4 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -6625,10 +6625,31 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) > return p; > } > > - if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) { > - /* XXX Don't handle blocked owners/delayed dequeue yet */ > + if (!READ_ONCE(owner->on_rq)) { > + /* > + * Owner is off the runqueue; proxy execution cannot > + * proceed through it. Deactivate the donor so it will > + * be properly re-enqueued when the owner eventually > + * wakes and releases the mutex. > + */ > return proxy_deactivate(rq, donor); > } > + if (owner->se.sched_delayed) { > + /* > + * The owner is in EEVDF's deferred-dequeue state: it > + * called schedule() but the scheduler kept it physically > + * on the runqueue because its lag was still positive. > + * This is a transient condition -- the owner will either > + * be woken (clearing sched_delayed) or fully dequeued > + * (clearing on_rq) very shortly. > + * > + * Unlike the !on_rq case the donor is still valid; do > + * not deactivate it. Yield to idle so the owner can > + * complete its state transition, then retry PE on the > + * next scheduling cycle. > + */ > + return proxy_resched_idle(rq); proxy_deactivate() is correct to do for now until we get to the blocked owner handling. > + } > > if (task_cpu(owner) != this_cpu) { > /* XXX Don't handle migrations yet */ -- Thanks and Regards, Prateek