From: Daniel Bristot de Oliveira <bristot@kernel.org>
To: Peter Zijlstra <peterz@infradead.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>,
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 14:48:16 +0200 [thread overview]
Message-ID: <bce68893-f4cd-cf93-5da7-ce98cc984c3a@kernel.org> (raw)
In-Reply-To: <20230616120507.GM83892@hirez.programming.kicks-ass.net>
On 6/16/23 14:05, Peter Zijlstra wrote:
> On Tue, Jun 13, 2023 at 03:41:30PM +0200, Daniel Bristot de Oliveira wrote:
>
>> In an 0-laxity scheduler, the server would run at 0-laxity, jumping in
>> front of DL tasks... that would break EDF. It would be mixing two
>> schedulers in one. It is not required and likely not a good idea either.
>
> I did consider a hybrid 0-laxity and EDF scheduler for mixed
> criticality, as have others like Ted Baker IIRC. IIRC it can be done
> using an augmented tree, but none of that solves the problems 0-laxity
> has (like over preemption and the general problem of playing chicken by
> doing things at the *VERY* last possible moment).
There are papers here or there about it, but it is far from being the most explored
way to do mixed criticality because of these side effects. It is more common to have
virtual deadlines for high and low criticalities, while using EDF.
Having EDF and being working conserving makes our life easier for other points
we are way behind, i.e., deadline inheritance.
> I think I did a talk at OSPERT on this at some point many years ago.
> Luckily some bright fellow had this semi-partitioned stuff that would
> make live much simpler :-)
It will, we can have two partitions, one for high and one for low. The general
case in the low power CPU, and if it does not make to finish on it, it continues
in the high power one. Still, always using EDF. Having virtual deadline is part
of semi-part. Anyways, EDF schedules more, and it is simpler... it is hard to beat.
This patch set is a warm up for that...
-- Daniel
next prev parent reply other threads:[~2023-06-16 12:48 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 [this message]
2023-06-19 12:02 ` Peter Zijlstra
2023-06-19 14:58 ` Daniel Bristot de Oliveira
2023-06-16 11:56 ` Peter Zijlstra
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=bce68893-f4cd-cf93-5da7-ce98cc984c3a@kernel.org \
--to=bristot@kernel.org \
--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=peterz@infradead.org \
--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