From: Daniel Bristot de Oliveira <bristot@redhat.com>
To: peterz@infradead.org, Juri Lelli <juri.lelli@redhat.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
Ingo Molnar <mingo@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>,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
patchwork-lst@pengutronix.de
Subject: Re: [PATCH] sched/deadline: Fix stale throttling on de-/boosted tasks
Date: Wed, 16 Sep 2020 09:40:03 +0200 [thread overview]
Message-ID: <bbcd9183-5a48-b3b1-516c-041db8e2f5aa@redhat.com> (raw)
In-Reply-To: <20200902094339.GZ1362448@hirez.programming.kicks-ass.net>
On 9/2/20 11:43 AM, peterz@infradead.org wrote:
> On Wed, Sep 02, 2020 at 08:00:24AM +0200, Juri Lelli wrote:
>> On 31/08/20 13:07, Lucas Stach wrote:
>>> When a boosted task gets throttled, what normally happens is that it's
>>> immediately enqueued again with ENQUEUE_REPLENISH, which replenishes the
>>> runtime and clears the dl_throttled flag. There is a special case however:
>>> if the throttling happened on sched-out and the task has been deboosted in
>>> the meantime, the replenish is skipped as the task will return to its
>>> normal scheduling class. This leaves the task with the dl_throttled flag
>>> set.
>>>
>>> Now if the task gets boosted up to the deadline scheduling class again
>>> while it is sleeping, it's still in the throttled state. The normal wakeup
>>> however will enqueue the task with ENQUEUE_REPLENISH not set, so we don't
>>> actually place it on the rq. Thus we end up with a task that is runnable,
>>> but not actually on the rq and neither a immediate replenishment happens,
>>> nor is the replenishment timer set up, so the task is stuck in
>>> forever-throttled limbo.
>>>
>>> Clear the dl_throttled flag before dropping back to the normal scheduling
>>> class to fix this issue.
>>>
>>> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>
>> Acked-by: Juri Lelli <juri.lelli@redhat.com>
I faced a similar issue, but involving DL tasks (not !DL):
https://lore.kernel.org/lkml/5076e003450835ec74e6fa5917d02c4fa41687e6.1600170294.git.bristot@redhat.com/
While debugging that problem, I reviewed and tested this patch,
and we need it. So:
Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Thanks!
-- Daniel
> Thanks!
>
next prev parent reply other threads:[~2020-09-16 7:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 11:07 Lucas Stach
2020-09-02 6:00 ` Juri Lelli
2020-09-02 9:43 ` peterz
2020-09-09 12:59 ` Lucas Stach
2020-09-16 7:40 ` Daniel Bristot de Oliveira [this message]
2020-09-29 7:56 ` [tip: sched/core] " tip-bot2 for Lucas Stach
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=bbcd9183-5a48-b3b1-516c-041db8e2f5aa@redhat.com \
--to=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=patchwork-lst@pengutronix.de \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
/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
all inboxes | Powered by JetHome®