From: Juri Lelli <juri.lelli@redhat.com>
To: luca abeni <luca.abeni@santannapisa.it>
Cc: peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
tommaso.cucinotta@santannapisa.it, alessio.balsini@gmail.com,
bristot@redhat.com, dietmar.eggemann@arm.com,
linux-rt-users@vger.kernel.org, mtosatti@redhat.com,
williams@redhat.com, valentin.schneider@arm.com
Subject: Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure
Date: Fri, 7 Aug 2020 15:30:41 +0200 [thread overview]
Message-ID: <20200807133041.GQ42956@localhost.localdomain> (raw)
In-Reply-To: <20200807151632.36dc6200@nowhere>
Hi Luca,
On 07/08/20 15:16, luca abeni wrote:
> Hi Juri,
>
> thanks for sharing the v2 patchset!
>
> In the next days I'll have a look at it, and try some tests...
Thanks!
> In the meanwhile, I have some questions/comments after a first quick
> look.
>
> If I understand well, the patchset does not apply deadline servers to
> FIFO and RR tasks, right? How does this patchset interact with RT
> throttling?
Well, it's something like the dual of it, in that RT Throttling directly
throttles RT tasks to make spare CPU cycles available to fair tasks
while this patchset introduces deadline servers to schedule fair tasks,
thus still reserving CPU time for those (when needed).
> If I understand well, patch 6/6 does something like "use deadline
> servers for SCHED_OTHER only if FIFO/RR tasks risk to starve
> SCHED_OTHER tasks"... Right?
That's the basic idea, yes.
> I understand this is because you do not
> want to delay RT tasks if they are not starving other tasks. But then,
> maybe what you want is not deadline-based scheduling. Maybe a
> reservation-based scheduler based on fixed priorities is what you want?
> (with SCHED_DEADLINE, you could provide exact performance guarantees to
> SCHED_OTHER tasks, but I suspect patch 6/6 breaks these guarantees?)
I agree that we are not interested in exact guarantees in this case, but
why not using something that it's already there and would give us the
functionality we need (fix starvation for fair)? It would also work well
in presence of "real" deadline tasks I think, in that you could account
for these fair servers while performing admission control.
Best,
Juri
next prev parent reply other threads:[~2020-08-07 13:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 9:50 [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure Juri Lelli
2020-08-07 9:50 ` [RFC PATCH v2 1/6] sched: Unify runtime accounting across classes Juri Lelli
2020-08-07 9:50 ` [RFC PATCH v2 2/6] sched/deadline: Collect sched_dl_entity initialization Juri Lelli
2020-08-07 9:50 ` [RFC PATCH v2 3/6] sched/deadline: Move bandwidth accounting into {en,de}queue_dl_entity Juri Lelli
2020-08-07 9:50 ` [RFC PATCH v2 4/6] sched/deadline: Introduce deadline servers Juri Lelli
2020-10-06 7:56 ` luca abeni
2020-10-06 9:35 ` Juri Lelli
2020-10-06 9:51 ` luca abeni
2020-08-07 9:50 ` [RFC PATCH v2 5/6] sched/fair: Add trivial fair server Juri Lelli
2020-08-07 9:56 ` [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor Juri Lelli
2020-08-07 10:46 ` peterz
2020-08-07 11:30 ` Daniel Bristot de Oliveira
2020-08-07 12:50 ` Juri Lelli
2020-08-07 13:49 ` luca abeni
2020-08-07 14:11 ` peterz
2020-08-07 16:48 ` Daniel Bristot de Oliveira
2020-08-07 13:28 ` luca abeni
2020-08-07 13:43 ` Juri Lelli
2020-08-07 13:55 ` luca abeni
2020-08-07 14:11 ` Juri Lelli
2020-08-07 14:13 ` peterz
2020-08-07 15:06 ` Juri Lelli
2020-08-07 13:16 ` [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure luca abeni
2020-08-07 13:30 ` Juri Lelli [this message]
2020-08-07 13:41 ` luca abeni
2020-08-07 14:04 ` Juri Lelli
2020-08-07 14:14 ` peterz
2020-09-08 22:22 ` Pavel Machek
2020-09-09 5:51 ` Juri Lelli
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=20200807133041.GQ42956@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=alessio.balsini@gmail.com \
--cc=bristot@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tommaso.cucinotta@santannapisa.it \
--cc=valentin.schneider@arm.com \
--cc=williams@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