All of lore.kernel.org
 help / color / mirror / Atom feed
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 6/6] sched/fair: Implement starvation monitor
Date: Fri, 7 Aug 2020 16:11:35 +0200	[thread overview]
Message-ID: <20200807141135.GT42956@localhost.localdomain> (raw)
In-Reply-To: <20200807155510.2b380f49@nowhere>

On 07/08/20 15:55, luca abeni wrote:
> On Fri, 7 Aug 2020 15:43:53 +0200
> Juri Lelli <juri.lelli@redhat.com> wrote:
> 
> > On 07/08/20 15:28, luca abeni wrote:
> > > Hi Juri,
> > > 
> > > On Fri, 7 Aug 2020 11:56:04 +0200
> > > Juri Lelli <juri.lelli@redhat.com> wrote:
> > >   
> > > > Starting deadline server for lower priority classes right away
> > > > when first task is enqueued might break guarantees  
> > > 
> > > Which guarantees are you thinking about, here? Response times of
> > > fixed priority tasks?  
> > 
> > Response time, but also wakeup latency (which, for better or worse, is
> > another important metric).
> > 
> > > If fixed priority tasks are also scheduled through deadline servers,
> > > then you can provide response-time guarantees to them even when
> > > lower-priority/non-real-time tasks are scheduled through deadline
> > > servers.  
> > 
> > Right, but I fear we won't be able to keep current behavior for
> > wakeups: RT with highest prio always gets scheduled right away?
> 
> Uhm... I think this depends on how the servers' parameters are
> designed: assigning "wrong" (or "bad") parameters to the server used to
> schedule RT tasks, this property is broken.
> 
> (however, notice that even with the current patchset the highest
> priority task might be scheduled with some delay --- if the SCHED_OTHER
> deadline server is active because SCHED_OTHER tasks are being starved).

But that's OK I think, because if the server is active it means that
OTHER didn't get a chance to run for some time and if it continues to
hung than worse problems than breaking FIFO assumptions will happen. :-/


  reply	other threads:[~2020-08-07 14:12 UTC|newest]

Thread overview: 30+ 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-08-07 13:03   ` kernel test robot
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 [this message]
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
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=20200807141135.GT42956@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 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.