From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.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>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
linux-kernel@vger.kernel.org,
Luca Abeni <luca.abeni@santannapisa.it>,
Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>,
Thomas Gleixner <tglx@linutronix.de>,
Vineeth Pillai <vineeth@bitbyteword.org>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [RFC PATCH V3 6/6] sched/fair: Implement starvation monitor
Date: Fri, 16 Jun 2023 13:56:24 +0200 [thread overview]
Message-ID: <20230616115624.GL83892@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <b2cd0072-d226-4adb-ddf5-958d9635f881@kernel.org>
On Mon, Jun 12, 2023 at 04:45:54PM +0200, Daniel Bristot de Oliveira wrote:
> On 6/12/23 03:57, Joel Fernandes wrote:
> > Lastly, if the goal is to remove RT throttling code eventually, are
> > you also planning to remove RT group scheduling as well? Are there
> > users of RT group scheduling that might be impacted? On the other
> > hand, RT throttling / group scheduling code can be left as it is
> > (perhaps documenting it as deprecated) and the server stuff can be
> > implemented via a CONFIG option.
>
> I think that the idea is to have the DL servers eventually replace the group
> schedule. But I also believe that it is better to start by solving the
> throttling and then moving to other constructions on top of the mechanism.
The big problem with the rt group scheduling mess is affinities. Other
than that, yes abosolutely, that crap needs to go.
next prev parent reply other threads:[~2023-06-16 11:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 15:58 [RFC PATCH V3 0/6] SCHED_DEADLINE server infrastructure Daniel Bristot de Oliveira
2023-06-08 15:58 ` [RFC PATCH V3 1/6] sched: Unify runtime accounting across classes Daniel Bristot de Oliveira
2023-06-13 13:24 ` Phil Auld
2023-06-16 14:30 ` Valentin Schneider
2023-06-08 15:58 ` [RFC PATCH V3 2/6] sched/deadline: Collect sched_dl_entity initialization Daniel Bristot de Oliveira
2023-06-13 13:25 ` Phil Auld
2023-06-16 14:31 ` Valentin Schneider
2023-06-08 15:58 ` [RFC PATCH V3 3/6] sched/deadline: Move bandwidth accounting into {en,de}queue_dl_entity Daniel Bristot de Oliveira
2023-06-16 14:31 ` Valentin Schneider
2023-06-08 15:58 ` [RFC PATCH V3 4/6] sched/deadline: Introduce deadline servers Daniel Bristot de Oliveira
2023-06-13 13:21 ` Phil Auld
2023-06-23 16:47 ` Valentin Schneider
2023-07-04 15:52 ` Daniel Bristot de Oliveira
2023-07-04 17:25 ` Joel Fernandes
2023-07-04 17:28 ` Joel Fernandes
2023-06-08 15:58 ` [RFC PATCH V3 5/6] sched/fair: Add trivial fair server Daniel Bristot de Oliveira
2023-06-16 12:59 ` Peter Zijlstra
2023-06-16 13:00 ` Daniel Bristot de Oliveira
2023-06-16 13:12 ` Peter Zijlstra
2023-06-16 13:18 ` Daniel Bristot de Oliveira
2023-06-08 15:58 ` [RFC PATCH V3 6/6] sched/fair: Implement starvation monitor Daniel Bristot de Oliveira
2023-06-12 1:57 ` Joel Fernandes
2023-06-12 14:45 ` Daniel Bristot de Oliveira
2023-06-12 20:35 ` Joel Fernandes
2023-06-13 13:41 ` Daniel Bristot de Oliveira
2023-06-13 15:32 ` Joel Fernandes
2023-06-14 13:45 ` Daniel Bristot de Oliveira
2023-06-14 14:15 ` Juri Lelli
2023-06-14 18:27 ` Joel Fernandes
2023-06-14 18:24 ` Joel Fernandes
2023-06-16 12:05 ` Peter Zijlstra
2023-06-16 12:48 ` Daniel Bristot de Oliveira
2023-06-19 12:02 ` Peter Zijlstra
2023-06-19 14:58 ` Daniel Bristot de Oliveira
2023-06-16 11:56 ` Peter Zijlstra [this message]
2023-06-16 11:51 ` Peter Zijlstra
2023-06-16 13:27 ` Daniel Bristot de Oliveira
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=20230616115624.GL83892@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bristot@kernel.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joel@joelfernandes.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@linutronix.de \
--cc=tommaso.cucinotta@santannapisa.it \
--cc=vincent.guittot@linaro.org \
--cc=vineeth@bitbyteword.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome