From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 499CC364E89 for ; Mon, 10 Aug 2026 16:19:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786378787; cv=none; b=G7nSlXkMBVf5WIj2MuKAqNLahLN3z5n4tpR8Jy5H/vFXhAfb17P9q3i2AJjhvJIwLhGQoikO30xo+DREPwhJgdcaVIPSUdVl/7lGN5YnJNzVZyJWtLSy4kP87OIEbZhReOA3LpQMAt90J7spoyDWeWImtI3tA2cXfvi9Vt/wQw4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786378787; c=relaxed/simple; bh=2NawDxWlk0NXxjEtEpSCFts4lxZd60kICKaHTqhXKNo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ntAbti4dV7QDfanJ6PuZuI/joTclXGyN21ETlDEqA1mgnqgNVChc2BfpYr4fcmqJ4AAL7qehN7PSGYehoiHZ2SsHOmRBVOS6Lv5FMxMwtPXZXLNXTrx1rzzzZOwoFqEG5rxR74JHY01A2MZEGpoFBZi5/M7F/L4pGpV195PTD3c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=iiqj2IMT; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="iiqj2IMT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=qG26A9wH2PZiDwDe1oYCve3ZkzGbpg4ZoDtBPX9VtWM=; b=iiqj2IMTjcrUA+wNFqC7SOQBG3 kXHZbbksqj3hFWOHFpeUKEWk3SW88pE77+qzm2961sSxl3jfMcxJm69h53FynBv7PZbfdpfRxeLDV nRuz+UATwqdXOeBkBgoVP0u7tqdNhiflCpt6CnGtnFUsHR37bZ6gKoirIlVL/bRBAfZGp84tdHYrx dZsL+32LlPeuanQyfYCbuAD9ylL0PJaNNuJ9W05WkcI4N22VRPUTCTmzwqeeQp9xrNJNxTFHap5V0 g7LoyB0hnK3kA62Igg9HdR+fflWn/dpwEqzyinCrH7OnTNZd83DRDnsbgze+jgoiahe3q++L5Ob3T j0aAJpmQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtSME-0000000Eh8n-1iVK; Mon, 10 Aug 2026 15:56:10 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id BA4F2300244; Mon, 10 Aug 2026 17:56:03 +0200 (CEST) Date: Mon, 10 Aug 2026 17:56:03 +0200 From: Peter Zijlstra To: John Stultz Cc: LKML , Christian Loehle , Juri Lelli , Joel Fernandes , Qais Yousef , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , K Prateek Nayak , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , Andrea Righi , kuyo chang , hupu , kernel-team@android.com Subject: Re: [RESEND][PATCH v31 1/9] sched/deadline: Ignore proxy-exec sched_yield() Message-ID: <20260810155603.GY776954@noisy.programming.kicks-ass.net> References: <20260807035232.1881495-1-jstultz@google.com> <20260807035232.1881495-2-jstultz@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260807035232.1881495-2-jstultz@google.com> On Fri, Aug 07, 2026 at 03:52:07AM +0000, John Stultz wrote: > From: Christian Loehle > > With proxy execution, rq->curr is the execution context while rq->donor is > the donating context. rq->curr's sched_yield() is dispatched through > the donor class so that proxy execution follows the effective scheduling > context. > > For SCHED_DEADLINE, this is too strong. yield_task_dl() does not just ask > for another task of equal priority to get to run, it marks the current DL > entity as yielded and forces it to sleep until replenishment. These > yield semantics are fundamentally different from FIFO/RR (where if no > equal-priority tasks are runnable, no harm done, they get picked again > immediately) or OTHER (also doesn't cause priority inversion), so do not > mix these semantics by ignoring a sched_yield() on DL donors. > > Fixes: 127b90315ca0 ("sched/proxy: Yield the donor task") > Acked-by: Juri Lelli > Signed-off-by: Christian Loehle > Signed-off-by: John Stultz > --- > kernel/sched/deadline.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 0f858b98c9aa3..3e89b3abeb278 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -2574,6 +2574,9 @@ static bool dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags) > */ > static void yield_task_dl(struct rq *rq) > { > + if (sched_proxy_exec() && rq->curr != rq->donor) > + return; > + > /* > * We make the task go to sleep until its current deadline by > * forcing its runtime to zero. This way, update_curr_dl() stops I am not sure... Yes, we should not yield the donor. However, completely ignoring the yield() is also wrong. Now, the only way to actually hit this is by doing yield() while being a lock owner. And arguably that is quite insane. But still, completely ignoring it sounds wrong too. Can't we 'queue' the yield and have it be effective the moment the donor goes away?