From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 704903B9DA6 for ; Tue, 24 Mar 2026 19:13:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774379627; cv=none; b=a8BBQdceUrQ2HalZmm4HU4xijPgYR0d/rHE5lLbw/8o7Bu8jjqwXQBfrteDwk4FNS6SfZkjABA2n7Wp5k5+zl4oVEncPv7pGHuXzX/CjMoIZFr/30isS8vJAY7la8QvGiC+yKNCiIMv30RmMgTuuKbUEmVjEM0+0TsFKLic4vdg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774379627; c=relaxed/simple; bh=s24gttX2fPobni+4uF5EYC/ETHJY8wNfhjrnD0ySd1E=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=u2TAtiUVM7NMmo6T46U7rOkIm0+FQTBfL1teVTm1XbZoV7QA5PTk8DKnsCFbgNYAt4M3AyG1BPrxWtg37qq+3acaO+bjT8+h/TEcFd4Lf8HabsnJ43zzCFGO8kdz60D+a9A0U0rsX0n0M75T9uNxDb5Va5M3Op9Bm7Meuap5NXw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FUSeRBya; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FUSeRBya" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2aec07e8aafso20081855ad.1 for ; Tue, 24 Mar 2026 12:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774379626; x=1774984426; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=bkKxrN4mK8grYtgcOZzbVYEk2bIMXF95k62kkx3vWTE=; b=FUSeRByaulyJkRjgwbGrdCMXUOJ2akYr2KneLUVDZHIQKGguB8twe5SJcJi/5HSCHX yajW8GIp3GvwSLuLlnccFkNvmLogKTaA9KBAmQxiDdHEH7ter6gBsj7I8biCFuI/rE/e Lkk9ZF36+hsPT2BPFJwmGmNszmCnxMEjClFKl5QoIoDetFeDS23yWvxeKchuiLWJRV9r tZpzUwvnUi6EiHzbkpqYeWt1IT6u1glJJ4f8aXekgm5I3X4aJuZCV00j8L3Mpu8FO37m MUhDRC8NVA8loG8JnNfKlNKVmKWg8fpuGrS92rH9lGVsjZQa/nCuyMtikJ87JEoQdb1M k+jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774379626; x=1774984426; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bkKxrN4mK8grYtgcOZzbVYEk2bIMXF95k62kkx3vWTE=; b=jkkUhoYHVhDL2DnWTSxsLvmJU5io7KwVeHtu+/CuDDyDeXG1wnENdsw1NRs93nFN3l MmOmIkwrZU3DcaiH9Hlvl8O+Oy+va9hpJ09VLQd92MDmKGNqR/QZevd9io3kARcDg7Xs xUJaicXsaqqx1khnpep5IdD1W9Mj7IoJqJvH8z5a2durPEPhyvk7kwTnOQTlrEbYTzF/ XHPoR2bxj3R1Mxv2YDiL1njv+taORNUKqVgoQT6FEdUr/+IcOffWq8xEh201OiTv0zzI WIvHVHjG50/RqSsSIaIsBVczz6tdjSFDRVI8yLWJwSFnMbk6ZTwydoMk2ubCb6GXDU58 lOLA== X-Gm-Message-State: AOJu0YxAUpiZ+Uhl1qdgthJiTReVCnnUsaEZMSPGrhcEz9H3QoeO/FPT j/Qo4ivy6utpSrmyLRpLAaXAq41yVFY07lCHKAQnlRqvo1y8OnHQqKHEa2ruWseFOCy2sMxj9vc iVm2yrRrr1ubxy/aMej8K0zvdc7BJVCfDP+T3zy/tJUOA/ri+IOYxNy7gJTmFLMlvKYBzSnskFj alebg+NLRNMK/17qTgMOpk3bDunhjS+Pg/wbjF5XPT7o4JfMSn X-Received: from pjvd16.prod.google.com ([2002:a17:90a:d990:b0:35b:a305:76f5]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:540f:b0:35b:9397:7073 with SMTP id 98e67ed59e1d1-35c0dd9aa90mr392920a91.30.1774379625457; Tue, 24 Mar 2026 12:13:45 -0700 (PDT) Date: Tue, 24 Mar 2026 19:13:18 +0000 In-Reply-To: <20260324191337.1841376-1-jstultz@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260324191337.1841376-1-jstultz@google.com> X-Mailer: git-send-email 2.53.0.1018.g2bb0e51243-goog Message-ID: <20260324191337.1841376-4-jstultz@google.com> Subject: [PATCH v26 03/10] sched: Fix potentially missing balancing with Proxy Exec From: John Stultz To: LKML Cc: John Stultz , K Prateek Nayak , Peter Zijlstra , 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 , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" K Prateek pointed out that with Proxy Exec, we may have cases where we context switch in __schedule(), while the donor remains the same. This could cause balancing issues, since the put_prev_set_next() logic short-cuts if (prev == next). With proxy-exec prev is the previous donor, and next is the next donor. Should the donor remain the same, but different tasks are picked to actually run, the shortcut will have avoided enqueuing the sched class balance callback. So, if we are context switching, add logic to catch the same-donor case, and trigger the put_prev/set_next calls to ensure the balance callbacks get enqueued. Reported-by: K Prateek Nayak Closes: https://lore.kernel.org/lkml/20ea3670-c30a-433b-a07f-c4ff98ae2379@amd.com/ Suggested-by: Peter Zijlstra Signed-off-by: John Stultz --- Cc: Joel Fernandes Cc: Qais Yousef Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Valentin Schneider Cc: Steven Rostedt Cc: Ben Segall Cc: Zimuzo Ezeozue Cc: Mel Gorman Cc: Will Deacon Cc: Waiman Long Cc: Boqun Feng Cc: "Paul E. McKenney" Cc: Metin Kaya Cc: Xuewen Yan Cc: K Prateek Nayak Cc: Thomas Gleixner Cc: Daniel Lezcano Cc: Suleiman Souhlal Cc: kuyo chang Cc: hupu Cc: kernel-team@android.com --- kernel/sched/core.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index dc044a405f83b..610e48cdb66a9 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6829,9 +6829,11 @@ static void __sched notrace __schedule(int sched_mode) pick_again: next = pick_next_task(rq, rq->donor, &rf); - rq_set_donor(rq, next); rq->next_class = next->sched_class; if (sched_proxy_exec()) { + struct task_struct *prev_donor = rq->donor; + + rq_set_donor(rq, next); if (unlikely(next->blocked_on)) { next = find_proxy_task(rq, next, &rf); if (!next) @@ -6839,7 +6841,27 @@ static void __sched notrace __schedule(int sched_mode) if (next == rq->idle) goto keep_resched; } + if (rq->donor == prev_donor && prev != next) { + struct task_struct *donor = rq->donor; + /* + * When transitioning like: + * + * prev next + * donor: B B + * curr: A B or C + * + * then put_prev_set_next_task() will not have done + * anything, since B == B. However, A might have + * missed a RT/DL balance opportunity due to being + * on_cpu. + */ + donor->sched_class->put_prev_task(rq, donor, donor); + donor->sched_class->set_next_task(rq, donor, true); + } + } else { + rq_set_donor(rq, next); } + picked: clear_tsk_need_resched(prev); clear_preempt_need_resched(); -- 2.53.0.1018.g2bb0e51243-goog