From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 015DC41CB5E for ; Tue, 11 Aug 2026 08:34:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786437247; cv=none; b=TDIVkX4FtPhyFJEoQB59nuOEBT+JRciI5pF8mHOQT+ktUKjCToeN8pWbcx3uQyVonLrRpn69ovEWpzmCJa4wCrA+euaGIRac7UDEzKcnZxU86sHBVnmjGIcD8BGMdAc20AUeyyolGv1lsxKtUNR8ZuC3a9BQplpLuQQ3HXgWZ4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786437247; c=relaxed/simple; bh=G3dg2GOJNruV4qWXdG8jHH9DCBSRiYYcZ23ZUyeu+FI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rkcfhSuHtBJamKqLLfvWBU5l9vJLX56r0CSyYuaOC0yN+VmEZMdHObZaMahlAPTWs+Ya+Cg9KFGUkdcCBTfTPLjI2ewd/kjyQ1Xwy9S3FBdooZ3V3drGkbqc0olio2uT28vvepr8GPc05Mc7sR4jv9FJR4gQB7PvFUXbez4UNwY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FBvpacM7; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Za7Gz5sC; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FBvpacM7"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Za7Gz5sC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786437243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F9MXy0tt5y6wBLD8Rs928SYEf9OATLSUbGyUGqZBJtI=; b=FBvpacM7iRD+mRZ8WycQQpqlq7Tf2j/nTpjaPVbgVjF7s7MC1qLVckjNXHxsgoodUtSYNW BhL5Js6Tub52RiofkQ/I04ZbqJ5UVFeHYFAt2n3OkKxNWW1mFHeYttUmJTHHccqYnQ6k7x LcXJOOV3UN6Ag2ehx43Ok/yk358JogA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-145-OjwLYz77PlOBuyIw5rVDzw-1; Tue, 11 Aug 2026 04:34:02 -0400 X-MC-Unique: OjwLYz77PlOBuyIw5rVDzw-1 X-Mimecast-MFC-AGG-ID: OjwLYz77PlOBuyIw5rVDzw_1786437241 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-47fd4ee0ac0so2146133f8f.2 for ; Tue, 11 Aug 2026 01:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786437241; x=1787042041; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=F9MXy0tt5y6wBLD8Rs928SYEf9OATLSUbGyUGqZBJtI=; b=Za7Gz5sC2DtnLkngj3QL+kfrPCXlNExM/G2TgLA8LUX1hc8QeB42EjMB+X3zaMB4ND x7wkX7AVEB66QR+yQrknd9Hd1oP9dfKaQyQhLGsHXArl5QBG+7BX7MCLxCXRj/QkkMum QhbISXZtr6G0z68yr9XW+nvZ8lBv0sXeFwve0w+G6EuO070M0w8Ftj2eYaDYhFS65cEi e2Q+HMvCDTumd1Rx6Z1xJb8qFVWVioYxBO5Ui5fJGSZwYIkXxcmBCQApJKcOM5wRVWsW hPYrAwCiWrk3LINHdRAkZJumHVujFuLmVUgS0t5hFERBwkO1R66k1spblHcIlw6gijbY qP6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786437241; x=1787042041; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=F9MXy0tt5y6wBLD8Rs928SYEf9OATLSUbGyUGqZBJtI=; b=pQC+bCX1dhC5uCYTpBGu0PtSfNYXQP86odWLXWV08Qx5o7XunO2j6oCRvQYQ458KZd t8RtL3qXiXOliwDuX3x0UjkSoH7aoSuwbvQHKXY62qjvTzjSz0FSu9IAkmF0i9edQFco LWSh167JRoT6wrizyJ4Q8nzlNS5bO8DTj1H8AW4BdCCyMP8D+pfXiLe4P925ClNyIn4I 55CgWlNl/b/x0eTCxW/TtE0TdCIBe0ZjzUeQeb/clVxpBeuRFOMXSasPBiNeHkKjCVXE WAvmU5l+l8QQ2mjYZs64xYhYX+hadQqOAttzHe0czyr0mHv+xoQrUasGD58+dyKVoEYs JeYg== X-Forwarded-Encrypted: i=1; AHgh+RrS7WLd8WDeNF9emIDOhxjV7YfO1zNQjcIKMU2UdQdL5l1ZyIbBuPbXbQjuL5IELGnlt6zZtCxCpxXCcJw=@vger.kernel.org X-Gm-Message-State: AOJu0YxeLQC8niDuo8Wf+Oyux3Qgy7wQIM3NtzY1ENE3/f33wXgzasUc b6agzwgwLk2PaSBbydobbN/tcZ8G7QR9LnWOiIUXPaY6jOR5O1kM827qYGFLHTl12rYk0pSjCsp EQBEcVpM9Y7Uvlj+kOxDXnWdzmRJTCeBF9so6fArxIB5cnsB7cJ0AjHC2VGkGOZmJdQ== X-Gm-Gg: AR+sD11BmSL6TRrDhsZabj7h5a7CD+Kv15TSkaQmMIibfbnRk7jBb2nau1tXAIPz/od uCExBrQWXTAP2O3Fif7gvj8NDNUaHnFoGi1EfcYBnt8tT8c54CEl44xOTbaVjfPwzTqVG8t/MCA aGBv3yWzUVaq03ZBoF8LHV1J9yq94udFWKiei0m1RCmM4oCJQcLodJ6ksRL8XSWeHp8wZy0rlED U4TZI4VpsJy6gT0j1F5a7fnvlus6ixAJYucu5aVktyfgzWRmT/tIWYu8uKE10d4z7IPfqUBjWcI +UenT/ZP1n/yBxEOwDx/dZA5j4CwF1hD6dCypn5nRASZv1rObZUiup+4cWRk8YojPZyXT+ALC00 3uu6QIzl85nEA/FJAzXMWIDrKYW5dqKg= X-Received: by 2002:a05:600c:b93:b0:495:4811:d71c with SMTP id 5b1f17b1804b1-4997846a4e8mr23898325e9.13.1786437240694; Tue, 11 Aug 2026 01:34:00 -0700 (PDT) X-Received: by 2002:a05:600c:b93:b0:495:4811:d71c with SMTP id 5b1f17b1804b1-4997846a4e8mr23897405e9.13.1786437240182; Tue, 11 Aug 2026 01:34:00 -0700 (PDT) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.92.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49977df9489sm48456255e9.1.2026.08.11.01.33.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 01:33:59 -0700 (PDT) Date: Tue, 11 Aug 2026 10:33:56 +0200 From: Juri Lelli To: K Prateek Nayak Cc: John Stultz , Peter Zijlstra , LKML , Christian Loehle , 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 , 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: References: <20260807035232.1881495-1-jstultz@google.com> <20260807035232.1881495-2-jstultz@google.com> <20260810155603.GY776954@noisy.programming.kicks-ass.net> <76bf6fb3-2406-4a01-a37d-1626ef34ae18@amd.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <76bf6fb3-2406-4a01-a37d-1626ef34ae18@amd.com> On 11/08/26 09:25, K Prateek Nayak wrote: > Hello John, Peter, > > On 8/11/2026 12:55 AM, John Stultz wrote: > > On Mon, Aug 10, 2026 at 8:57 AM Peter Zijlstra wrote: > >> 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. > > > > Ok. I'll drop this out of my current submission series. > > > >> > >> Can't we 'queue' the yield and have it be effective the moment the donor > >> goes away? > > Question: What does rt_mutex do in this case? > > From my limited understanding, for rt_mutex, we hit the is_dl_boosted(dl_se) > condition in the throttle label in update_curr_dl_se() and then we do a: > > enqueue_task_dl(rq, dl_task_of(dl_se), ENQUEUE_REPLENISH); > > Would same work for proxy too where we can essentially consider > "dl_task(donor) && rq->donor != rq->curr" as is_dl_boosted() and continue > with the "boost overrides the throttle" rule? I believe we want to remove the existing hack once we have proxy execution in place. At that point we should be able to enfore bandwidth properly across inheritance chains. yield() while holding a lock is indeed insane in theory, but in practice one might not be in full control of what other software layers are doing. So, maybe what Peter is proposing could be a viable practical middle ground. Wonder if should anyway at least WARN about it.