From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011027.outbound.protection.outlook.com [40.107.208.27]) (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 6B1433CB8EB for ; Fri, 26 Jun 2026 05:52:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.27 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782453169; cv=fail; b=mbYDiTwhGUq+4zDaAwrn8WbPTLH6kn8PfTNTTVxPZVWbT6pN3dXwh0pJLa6h6RFnC6ZN6H7RWezQf+7qQcZSlWsEOOVQzLv0kpbLDzG+0k5PPdyWufukGZjwDXBA1Dl9VyNdbIxFR536TGp4YD1agjzeKAadT/g4Axm9CtF2Q28= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782453169; c=relaxed/simple; bh=5xtBZV+jLAYfVFbPMHKbHYcBtXL20QAMBwdrEuZsz8U=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Xt1BES0HCnKYtB9UeygaeNj+Y1anI7ijEbw+mctXbsy/6FN6xp7BK1F01yAHyxGLO6kdRCtiJeKXXHL8ONmvjDqyxUvI7iXN++K/HTHEnyiuHZZ2LTqID49eCZvRtzcn8Jn1oolB5CeNbq8UvUAuR+hV88h1DBOF0wy62Mmi6c0= 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=2FszFNNz; arc=fail smtp.client-ip=40.107.208.27 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="2FszFNNz" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WIt0CrPGAOok1n5Eii3qWOJJgMcIQNqTbSlRthSN/fiVSzWR82yJ0yYSd6uyrhfyjuB7XqIOdVii3sH1xmCF7gQT3zPLObC8cssqHCOw18XtHv2TOfI4eEW1/8B3/NsQR2zXJ9Yokc4BKITWfkqVo9qB0MrcRV5YH+kowjKK1epYpRpm2Ss/QkCs/HnWTdoafIAJ5FNXSr6J/8wpJYCqB4uCax5eU0rW6fG37P4QlpvGXLzdTbkLzElICsM/gnCv+6KMsAk/2YoqyxwSh78qkVHaYPesQymZsM+WQbGlCKwXpi9w/Hu5ALUJJ4GxK8cwaRjJvkRqq3F0RffabTnOwg== 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=ZfFWUYf9iwvAP/RCRnS7hIGssVcdRPvKdHnO+R1ATVY=; b=Tmi1Xak8Gs+22JrBFTgUNZrosYU7MKbKC7G0fpyiKfz5bQKQ2rAB50aX71qoB/0zMfREdsob/GMYlmkGL911JmwI/FwAbtYueIWrteoasyEM4o5aN00oSkxsPrZrzXDVOKc8Y5IB2pgbBaj4xJ3RvlciNGBBh8RxJ1JoFvdFdDPK1nr1+yqytfzOQTDVsvPyr2yGHlJCetE1Ww1iINRbDh44hcz2G/qNWGyYTbI8IVCsW7dv2845M3qGbri1q4LC89vwrIm9ZJ/lB1kC3DGmm3wUc7f2p+9raZlujfghJMyMz8UIGl4Kat3gNZqS7bqKUQg3YP2TTKqIaKM/24Dnsw== 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=ZfFWUYf9iwvAP/RCRnS7hIGssVcdRPvKdHnO+R1ATVY=; b=2FszFNNz5W6xBGHjpkIBWF1JPQvk95k/wNIFsWoWIAVFHWtH7VCeJMKCCTSzy+0vLx1KskQhhJQ6ksAOlj/5w0TuL13eoFutyiG0dmL2cM5xUCOkEgbukiMhCM/sSm6Jj2Fdkg8mTt+eJExhl0/GpW78bVWT9LGDw8bjkrc0PI4= Received: from BYAPR21CA0011.namprd21.prod.outlook.com (2603:10b6:a03:114::21) by DM4PR12MB6589.namprd12.prod.outlook.com (2603:10b6:8:b4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.139.20; Fri, 26 Jun 2026 05:52:40 +0000 Received: from BY1PEPF0001AE1B.namprd04.prod.outlook.com (2603:10b6:a03:114:cafe::93) by BYAPR21CA0011.outlook.office365.com (2603:10b6:a03:114::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.181.6 via Frontend Transport; Fri, 26 Jun 2026 05:52:40 +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 BY1PEPF0001AE1B.mail.protection.outlook.com (10.167.242.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.6 via Frontend Transport; Fri, 26 Jun 2026 05:52:40 +0000 Received: from satlexmb10.amd.com (10.181.42.219) 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.41; Fri, 26 Jun 2026 00:52:39 -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.41; Fri, 26 Jun 2026 00:52:39 -0500 Received: from [10.136.35.225] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Fri, 26 Jun 2026 00:52:35 -0500 Message-ID: <8e2d6d3a-b4d5-48fc-a530-be54897198f5@amd.com> Date: Fri, 26 Jun 2026 11:22:35 +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 v2] sched/rt: Push RT tasks when preempted by a deadline task To: yangsonghua , Ingo Molnar , Peter Zijlstra CC: Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Valentin Schneider , , yangsonghua References: <20260626032326.6581-1-yangsonghua@lixiang.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260626032326.6581-1-yangsonghua@lixiang.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE1B:EE_|DM4PR12MB6589:EE_ X-MS-Office365-Filtering-Correlation-Id: 529d9ec5-d5ec-4375-1be2-08ded347225f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|7416014|376014|30052699003|1800799024|23010399003|36860700016|18002099003|22082099003|56012099006|11063799006|6133799003|5023799004|13003099007; X-Microsoft-Antispam-Message-Info: RRjwMxVeMCjeU0h6UI3yRwqTG8/vw/wNBoNaf1wlG78FFgBK4KRHl/6B+tSln8EFQrHcJXrr3oDHj/zGacLo0nbtEc/3buvR2naaLF3lFoNrpPsck1crrzaejjkhACkwERM0FsblKAxWxWinkya0OVe/ZrTuh4ODoqhHFHkH+mcfLOfDFPf8Z8OVl6CAPtViVXmsk9FMFjRx4aT091+dEn1tdY0iVlwwB/XYju2ZIHJs7K7hZZRxrjE7R9IWlimhQb9ts/nosb/x74TlTLrQvuHKgyqOP8p45rlCJE7kM+iN+sp050D5163452rWir+SzLADY8J61IugGE1f8o/DjYhprlVNZbXYSs68s4dDXmXAIx3TtwuZu0ZqrNQnb1j4pOWQRZDIURbYPNAbTXB8gcnE4I4IgQiuQ1EF5aKp8okY8e4EwrXryi8lFvt+q73XukspQzUUsiol5s1pSkrJMpK58dwqYIb+fAfz+oSwhAWqyaLw55GWWsUPtSS831vf1VCJARiMFKjErUON7JvUkYovo70AndW/7kO9kIQe105Q2TDpdD8cO4owT8dOv9xu3TldMkNn241TL4bnZiOZwcPm1/KFBsEtggtewQq3zBbWsskLFa2LpKC2MJf9+oe4PYvs+mLtcphsJLL88cdvpuAxecY2V+vAxoZ5ev9LwePXhlFXccCFaBHdEyM0R+CduYIKO0joFbUqdaReXdBKxQ== 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)(7416014)(376014)(30052699003)(1800799024)(23010399003)(36860700016)(18002099003)(22082099003)(56012099006)(11063799006)(6133799003)(5023799004)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ileTlsxcNeZdjroUGOQMSlGMXOVrk62l6h4EkZ4n0unN9h+ac+FkeGAL2Z/31bTGW6FvMbACNAJjVqGrR87CTttz1QB6y93PK/hxa75LLYtg9qOqlvELdgTfQR62u2yaVdTSj3k5ejGtYWWYbfW0ah6Cw9zl9LQfvi97SMVSOCs1V7uiYodY7PUE0yKSejlLrLipoT+wu+bt6idtZVV6zbXOY0JdhnWn0LtQQIthvwf4QgoZQTfqtHCAHEeH02fKsetcRG93naJKxVsJdk6ejmn2us9nKjr8BfS/De7APgMf8J7bv3Qfx8nFW6go0bzPzcUCQqeVDVuvP560nvirAyAsGUoyIC4SpRpQfFM5QGmja6PTNfmCSWZj34prkLo1lf5kTNDP/a6DXhk/uwze6n4Fz6dcUt07opAcdk4/krZYWajDT6ijc/O0+5gYdMWy X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2026 05:52:40.4633 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 529d9ec5-d5ec-4375-1be2-08ded347225f 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: BY1PEPF0001AE1B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6589 Hello Yangsonghua, On 6/26/2026 8:53 AM, yangsonghua wrote: > [You don't often get email from jluyangsonghua@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Commit 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() > and rq_modified_*()") made wakeup_preempt_rt() callable for cross-class > wakeups, leaving a "XXX If we're preempted by DL, queue a push?" comment > with no implementation. > > When a SCHED_DEADLINE task preempts a running SCHED_FIFO/SCHED_RR task, > the RT class's put_prev_task_rt() is the natural place to trigger a push: > at that point the preempted task is (conditionally) added to > pushable_tasks, and we have 'next' available to identify the reason for > preemption. > > The earlier wakeup_preempt_rt() call site is too early: the running RT > task has not yet been added to pushable_tasks, so rt_queue_push_tasks() > would be a no-op for the common single-RT-task-per-CPU case. > > Guard the dl_task(next) check with a NULL test. put_prev_task_rt() is > reachable with next == NULL when called via the bare put_prev_task() > wrapper (sched.h), which always passes NULL: > > sched_change_begin() > put_prev_task(rq, p) /* next = NULL */ > put_prev_task_rt(rq, p, NULL) > dl_task(NULL) -> NULL deref /* BUG in v1 */ > > The actual DL-preemption path goes through put_prev_set_next_task(), > which supplies the real next task, so the NULL guard does not change > the intended trigger condition. > > Regarding potentially unnecessary push/pull cycles for short-lived DL > tasks: this is an inherent property of any asynchronous push mechanism. > rt_queue_push_tasks() enqueues a balance callback rather than migrating > synchronously, so by the time it fires the DL task may have already > yielded; in that case the RT task may need to be pulled back. This > trade-off is acceptable: leaving RT tasks stranded on a busy CPU > while peer CPUs sit idle is worse than an occasional redundant > migration. The same concern applies to the existing triggers of > rt_queue_push_tasks() (e.g. after dequeue_task_rt), so this path is > consistent with the established policy. > > Fix this by adding a dl_task(next) check in put_prev_task_rt(), guarded > against NULL. This is intentionally placed outside and after the > enqueue_pushable_task() condition, so that a push is triggered even when > the preempted RT task is pinned (nr_cpus_allowed == 1) or blocked > (proxy-exec): in those cases there may be other migratable RT tasks > already sitting in pushable_tasks. That cannot be the case. More details below. > > The task_is_blocked() early-return is folded into the > enqueue_pushable_task() condition to avoid inadvertently suppressing the > new push logic. > > Note: this does not cover the DL-server case where a fair-class task > running under DL bandwidth budget displaces an RT task; that is a > separate concern. > > Signed-off-by: yangsonghua > --- > Changes in v2: > - Guard dl_task(next) with a 'next != NULL' check to fix a NULL pointer > dereference when put_prev_task_rt() is called from sched_change_begin() > via the put_prev_task() wrapper, which always passes next = NULL. > - Extend the commit message to explain the NULL call path and address the > reviewer concern about unnecessary push/pull cycles for short-lived DL > tasks. > - Improve wakeup_preempt_rt() comment to explicitly point readers to > put_prev_task_rt() where the DL push is now handled. > > kernel/sched/rt.c | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index e474c31d8fe6..ef8cdc4c25d2 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -1627,7 +1627,10 @@ static void wakeup_preempt_rt(struct rq *rq, struct task_struct *p, int flags) > struct task_struct *donor = rq->donor; > > /* > - * XXX If we're preempted by DL, queue a push? > + * If the incoming task belongs to a higher-priority class (e.g. DL), > + * we only handle same-class RT preemption here. The DL case is > + * handled in put_prev_task_rt() once the current task has been > + * added to pushable_tasks. > */ > if (p->sched_class != &rt_sched_class) > return; > @@ -1736,14 +1739,25 @@ static void put_prev_task_rt(struct rq *rq, struct task_struct *p, struct task_s > > update_rt_rq_load_avg(rq_clock_pelt(rq), rq, 1); > > - if (task_is_blocked(p)) > - return; I still don't get why we are removing this early return. When "p" was selected to run, it would have already queued a balance callback via set_nex_task_rt() and the balance would have been done during last __schedule(). If there are pushable tasks on the list still, they'll still remain non-pushable since they haven't run on CPU and nothing has changed for them to suddenly enable a movement. "p" itself is a blocked task so it cannot be moved - it'll simply follow the lock owner via proxy migration path whenever it gets a chance. So the gist is: If there are pushable tasks, then balance failed to move them previously. If the state of the system had changed, balance_rt() on a remote CPU would have already pulled the highest priority task from this rq. I feel that early return for blocked task should stay as is since there is no opportunity for balance yet unless I'm missing something. > /* > * The previous task needs to be made eligible for pushing > - * if it is still active > + * if it is still active and migratable. > */ > - if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1) > + if (!task_is_blocked(p) && on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1) > enqueue_pushable_task(rq, p); > + > + /* > + * When a deadline task takes over this CPU, try to push any queued > + * RT tasks to CPUs running lower-priority work. This is independent > + * of whether p itself is pushable: even if p is pinned or blocked, > + * there may be other migratable RT tasks already in pushable_tasks. > + * > + * next is NULL when called from put_prev_task() (e.g. sched_change_begin); > + * guard accordingly. rt_queue_push_tasks() checks has_pushable_tasks() > + * internally, so this is a no-op if nothing is queued. > + */ > + if (next && dl_task(next)) > + rt_queue_push_tasks(rq); Based on some quick look at the cpupri bits, I think this makes sense. Since we try to move "p" to a CPU running a lower priority task and a deadline task would have increased the priority of this CPU anyways, it is fair to attempt a push. I'll let Steve finish his metamorphosis and see if that estimate is wrong or not ;-) > } > > /* Only try algorithms three times */ > -- > 2.34.1 > -- Thanks and Regards, Prateek