From: Peter Zijlstra <peterz@infradead.org>
To: Joel Fernandes <joelagnelf@nvidia.com>
Cc: linux-kernel@vger.kernel.org, Andrea Righi <arighi@nvidia.com>,
Tejun Heo <tj@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
Luigi De Matteis <ldematteis123@gmail.com>,
paulmck@kernel.org, boqun.feng@gmail.com
Subject: Re: [PATCH RFC 3/8] sched/ext: Add a DL server for sched_ext tasks
Date: Mon, 17 Mar 2025 11:31:01 +0100 [thread overview]
Message-ID: <20250317103101.GC34541@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <3b244939-6d55-4d86-8b77-a9a7629f8239@nvidia.com>
On Sat, Mar 15, 2025 at 07:15:27PM -0400, Joel Fernandes wrote:
>
>
> On 3/15/2025 3:22 AM, Peter Zijlstra wrote:
> > On Fri, Mar 14, 2025 at 10:21:50PM -0400, Joel Fernandes wrote:
> >> sched_ext currently suffers starvation due to RT. The same workload when
> >> converted to EXT can get zero runtime if RT is 100% running, causing EXT
> >> processes to stall. Fix it by adding a DL server for EXT.
> >
> > This needs a lot more words on why you need a second server. Because I
> > don't think you do.
>
> Sure, I will add more words to the change log to explain rationale. When you say
> "I don't think you do", do you mean that both FAIR and EXT could be served by
> the same server?
Yeah, because now you get two deadline entities both having a
reservation on bandwidth. One of which is not going to be used -- this
is not nice.
> If so, that will not handle the case where the system has both
> FAIR and EXT tasks in the mix (EXT has a partial mode where certain tasks can be
> made EXT with certain others left as FAIR) and FAIR runs 100% and starves EXT.
Well, you did not mention that issue, you only babbled about RT.
I did point out that issue with ext, and TJ said this mixed mode wasn't
really meant to be used or somesuch.
So if that's changed, this needs a separate discussion.
Also; I gotta ask, why is nvidia looking at ext ?
next prev parent reply other threads:[~2025-03-17 10:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 2:21 [PATCH RFC 0/8] Add a deadline server for sched_ext tasks Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 1/8] sched: Add support to pick functions to take rf Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 2/8] sched: Add a server arg to dl_server_update_idle_time() Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 3/8] sched/ext: Add a DL server for sched_ext tasks Joel Fernandes
2025-03-15 7:22 ` Peter Zijlstra
2025-03-15 23:15 ` Joel Fernandes
2025-03-17 10:31 ` Peter Zijlstra [this message]
2025-03-17 16:57 ` Tejun Heo
2025-03-17 17:06 ` Peter Zijlstra
2025-03-17 21:48 ` Joel Fernandes
2025-03-17 22:16 ` Tejun Heo
2025-03-17 22:39 ` Joel Fernandes
2025-03-17 22:48 ` Tejun Heo
2025-03-18 10:07 ` Joel Fernandes
2025-03-17 21:53 ` Joel Fernandes
2025-03-15 17:56 ` Andrea Righi
2025-03-15 23:17 ` Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 4/8] sched/debug: Fix updating of ppos on server write ops Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 5/8] sched/debug: Stop and start server based on if it was active Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 6/8] sched/debug: Add support to change sched_ext server params Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 7/8] sched/deadline: Clear defer params Joel Fernandes
2025-03-15 2:21 ` [PATCH RFC 8/8] selftests/sched_ext: Add test for sched_ext dl_server Joel Fernandes
2025-03-15 23:22 ` Joel Fernandes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250317103101.GC34541@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arighi@nvidia.com \
--cc=boqun.feng@gmail.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelagnelf@nvidia.com \
--cc=juri.lelli@redhat.com \
--cc=ldematteis123@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.