* Re: [PATCH] Revert "sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks"
2025-09-26 15:34 ` Matt Fleming
@ 2025-09-29 3:53 ` K Prateek Nayak
2025-10-14 10:15 ` Matt Fleming
2025-10-15 6:03 ` [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue K Prateek Nayak
2025-10-23 4:03 ` [PATCH 6.17] " K Prateek Nayak
2 siblings, 1 reply; 14+ messages in thread
From: K Prateek Nayak @ 2025-09-29 3:53 UTC (permalink / raw)
To: Matt Fleming
Cc: John Stultz, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, linux-kernel, kernel-team,
Matt Fleming, Oleg Nesterov, Chris Arges, stable
Hello Matt,
On 9/26/2025 9:04 PM, Matt Fleming wrote:
> On Fri, Sep 26, 2025 at 3:43 AM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>>
>> Hello John, Matt,
>>
>> On 9/26/2025 5:35 AM, John Stultz wrote:
>>>
>>> However, there are two spots where we might exit dequeue_entities()
>>> early when cfs_rq_throttled(rq), so maybe that's what's catching us
>>> here?
>>
>> That could very likely be it.
>
> That tracks -- we're heavy users of cgroups and this particular issue
> only appeared on our kubernetes nodes.
>
>> Matt, if possible can you try the patch attached below to check if the
>> bailout for throttled hierarchy is indeed the root cause. Thanks in
>> advance.
>
> I've been running our reproducer with this patch for the last few
> hours without any issues, so the fix looks good to me.
>
> Tested-by: Matt Fleming <mfleming@cloudflare.com>
Thank you for testing the diff. I see Ingo has already posted the
scheduler pull for v6.18 which indirectly solves this by removing those
early returns.
Once that lands, I'll attach a formal commit log and send out a patch
targeting the stable kernels >= 6.12.
--
Thanks and Regards,
Prateek
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Revert "sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks"
2025-09-29 3:53 ` K Prateek Nayak
@ 2025-10-14 10:15 ` Matt Fleming
0 siblings, 0 replies; 14+ messages in thread
From: Matt Fleming @ 2025-10-14 10:15 UTC (permalink / raw)
To: K Prateek Nayak
Cc: John Stultz, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, linux-kernel, kernel-team,
Matt Fleming, Oleg Nesterov, Chris Arges, stable
On Mon, Sep 29, 2025 at 09:23:06AM +0530, K Prateek Nayak wrote:
>
> Thank you for testing the diff. I see Ingo has already posted the
> scheduler pull for v6.18 which indirectly solves this by removing those
> early returns.
>
> Once that lands, I'll attach a formal commit log and send out a patch
> targeting the stable kernels >= 6.12.
Hey Prateek, I see the merge window is closed. Do you have plans to
submit a patch for stable now?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-09-26 15:34 ` Matt Fleming
2025-09-29 3:53 ` K Prateek Nayak
@ 2025-10-15 6:03 ` K Prateek Nayak
2025-10-15 6:14 ` Greg Kroah-Hartman
2025-10-23 4:03 ` [PATCH 6.17] " K Prateek Nayak
2 siblings, 1 reply; 14+ messages in thread
From: K Prateek Nayak @ 2025-10-15 6:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin, stable, Matt Fleming,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
linux-kernel
Cc: Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, kernel-team, Matt Fleming, Oleg Nesterov,
John Stultz, Chris Arges, K Prateek Nayak
Dequeuing a fair task on a throttled hierarchy returns early on
encountering a throttled cfs_rq since the throttle path has already
dequeued the hierarchy above and has adjusted the h_nr_* accounting till
the root cfs_rq.
dequeue_entities() crucially misses calling __block_task() for delayed
tasks being dequeued on the throttled hierarchies, but this was mostly
harmless until commit b7ca5743a260 ("sched/core: Tweak
wait_task_inactive() to force dequeue sched_delayed tasks") since all
existing cases would re-enqueue the task if task_on_rq_queued() returned
true and the task would eventually be blocked at pick after the
hierarchy was unthrottled.
wait_task_inactive() is special as it expects the delayed task on
throttled hierarchy to reach the blocked state on dequeue but since
__block_task() is never called, task_on_rq_queued() continues to return
true. Furthermore, since the task is now off the hierarchy, the pick
never reaches it to fully block the task even after unthrottle leading
to wait_task_inactive() looping endlessly.
Remedy this by calling __block_task() if a delayed task is being
dequeued on a throttled hierarchy.
This fix is only required for stabled kernels implementing delay dequeue
(>= v6.12) before v6.18 since upstream commit e1fad12dcb66 ("sched/fair:
Switch to task based throttle model") indirectly fixes this by removing
the early return conditions in dequeue_entities() as part of the per-task
throttle feature.
Cc: stable@vger.kernel.org
Reported-by: Matt Fleming <matt@readmodwrite.com>
Closes: https://lore.kernel.org/all/20250925133310.1843863-1-matt@readmodwrite.com/
Fixes: b7ca5743a260 ("sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks")
Tested-by: Matt Fleming <mfleming@cloudflare.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
Greg, Sasha,
This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
know if you would like me to send a seperate patch for each.
As mentioned above, the upstream fixes this as a part of larger feature
and we would only like these bits backported. If there are any future
conflicts in this area during backporting, I would be more than happy to
help out resolve them.
---
kernel/sched/fair.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index af61769b1d50..b3d9826e25b0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7187,6 +7187,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
int h_nr_delayed = 0;
struct cfs_rq *cfs_rq;
u64 slice = 0;
+ int ret = 0;
if (entity_is_task(se)) {
p = task_of(se);
@@ -7218,7 +7219,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
/* end evaluation on encountering a throttled cfs_rq */
if (cfs_rq_throttled(cfs_rq))
- return 0;
+ goto out;
/* Don't dequeue parent if it has other entities besides us */
if (cfs_rq->load.weight) {
@@ -7261,7 +7262,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
/* end evaluation on encountering a throttled cfs_rq */
if (cfs_rq_throttled(cfs_rq))
- return 0;
+ goto out;
}
sub_nr_running(rq, h_nr_queued);
@@ -7273,6 +7274,8 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
rq->next_balance = jiffies;
+ ret = 1;
+out:
if (p && task_delayed) {
SCHED_WARN_ON(!task_sleep);
SCHED_WARN_ON(p->on_rq != 1);
@@ -7288,7 +7291,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
__block_task(rq, p);
}
- return 1;
+ return ret;
}
/*
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-10-15 6:03 ` [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue K Prateek Nayak
@ 2025-10-15 6:14 ` Greg Kroah-Hartman
2025-10-15 6:27 ` K Prateek Nayak
0 siblings, 1 reply; 14+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-15 6:14 UTC (permalink / raw)
To: K Prateek Nayak
Cc: Sasha Levin, stable, Matt Fleming, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, linux-kernel, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
kernel-team, Matt Fleming, Oleg Nesterov, John Stultz,
Chris Arges
On Wed, Oct 15, 2025 at 06:03:59AM +0000, K Prateek Nayak wrote:
> Dequeuing a fair task on a throttled hierarchy returns early on
> encountering a throttled cfs_rq since the throttle path has already
> dequeued the hierarchy above and has adjusted the h_nr_* accounting till
> the root cfs_rq.
>
> dequeue_entities() crucially misses calling __block_task() for delayed
> tasks being dequeued on the throttled hierarchies, but this was mostly
> harmless until commit b7ca5743a260 ("sched/core: Tweak
> wait_task_inactive() to force dequeue sched_delayed tasks") since all
> existing cases would re-enqueue the task if task_on_rq_queued() returned
> true and the task would eventually be blocked at pick after the
> hierarchy was unthrottled.
>
> wait_task_inactive() is special as it expects the delayed task on
> throttled hierarchy to reach the blocked state on dequeue but since
> __block_task() is never called, task_on_rq_queued() continues to return
> true. Furthermore, since the task is now off the hierarchy, the pick
> never reaches it to fully block the task even after unthrottle leading
> to wait_task_inactive() looping endlessly.
>
> Remedy this by calling __block_task() if a delayed task is being
> dequeued on a throttled hierarchy.
>
> This fix is only required for stabled kernels implementing delay dequeue
> (>= v6.12) before v6.18 since upstream commit e1fad12dcb66 ("sched/fair:
> Switch to task based throttle model") indirectly fixes this by removing
> the early return conditions in dequeue_entities() as part of the per-task
> throttle feature.
>
> Cc: stable@vger.kernel.org
> Reported-by: Matt Fleming <matt@readmodwrite.com>
> Closes: https://lore.kernel.org/all/20250925133310.1843863-1-matt@readmodwrite.com/
> Fixes: b7ca5743a260 ("sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks")
> Tested-by: Matt Fleming <mfleming@cloudflare.com>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
> Greg, Sasha,
>
> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
> know if you would like me to send a seperate patch for each.
>
> As mentioned above, the upstream fixes this as a part of larger feature
> and we would only like these bits backported. If there are any future
> conflicts in this area during backporting, I would be more than happy to
> help out resolve them.
Why not just backport all of the mainline changes instead? As I say a
lot, whenever we do these "one off" changes, it's almost always wrong
and causes problems over the years going forward as other changes around
the same area can not be backported either.
So please, try to just backport the original commits.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-10-15 6:14 ` Greg Kroah-Hartman
@ 2025-10-15 6:27 ` K Prateek Nayak
2025-10-15 7:27 ` Greg Kroah-Hartman
0 siblings, 1 reply; 14+ messages in thread
From: K Prateek Nayak @ 2025-10-15 6:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, stable, Matt Fleming, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, linux-kernel, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
kernel-team, Matt Fleming, Oleg Nesterov, John Stultz,
Chris Arges
Hello Greg,
On 10/15/2025 11:44 AM, Greg Kroah-Hartman wrote:
>> Greg, Sasha,
>>
>> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
>> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
>> know if you would like me to send a seperate patch for each.
>>
>> As mentioned above, the upstream fixes this as a part of larger feature
>> and we would only like these bits backported. If there are any future
>> conflicts in this area during backporting, I would be more than happy to
>> help out resolve them.
>
> Why not just backport all of the mainline changes instead? As I say a
> lot, whenever we do these "one off" changes, it's almost always wrong
> and causes problems over the years going forward as other changes around
> the same area can not be backported either.
>
> So please, try to just backport the original commits.
Peter was in favor of backporting just the necessary bits in
https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
Backporting the whole of per-task throttle feature is lot more heavy
handed with the core changes adding:
include/linux/sched.h | 5 +
kernel/sched/core.c | 3 +
kernel/sched/fair.c | 451 ++++++++++++++++++++++++------------------
kernel/sched/pelt.h | 4 +-
kernel/sched/sched.h | 7 +-
5 files changed, 274 insertions(+), 196 deletions(-)
And a few more fixes that will add to the above before v6.18. I'll defer
to Peter to decide the best course of action.
--
Thanks and Regards,
Prateek
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-10-15 6:27 ` K Prateek Nayak
@ 2025-10-15 7:27 ` Greg Kroah-Hartman
2025-10-15 8:22 ` Peter Zijlstra
0 siblings, 1 reply; 14+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-15 7:27 UTC (permalink / raw)
To: K Prateek Nayak
Cc: Sasha Levin, stable, Matt Fleming, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, linux-kernel, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
kernel-team, Matt Fleming, Oleg Nesterov, John Stultz,
Chris Arges
On Wed, Oct 15, 2025 at 11:57:19AM +0530, K Prateek Nayak wrote:
> Hello Greg,
>
> On 10/15/2025 11:44 AM, Greg Kroah-Hartman wrote:
> >> Greg, Sasha,
> >>
> >> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
> >> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
> >> know if you would like me to send a seperate patch for each.
> >>
> >> As mentioned above, the upstream fixes this as a part of larger feature
> >> and we would only like these bits backported. If there are any future
> >> conflicts in this area during backporting, I would be more than happy to
> >> help out resolve them.
> >
> > Why not just backport all of the mainline changes instead? As I say a
> > lot, whenever we do these "one off" changes, it's almost always wrong
> > and causes problems over the years going forward as other changes around
> > the same area can not be backported either.
> >
> > So please, try to just backport the original commits.
>
> Peter was in favor of backporting just the necessary bits in
> https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
>
> Backporting the whole of per-task throttle feature is lot more heavy
> handed with the core changes adding:
>
> include/linux/sched.h | 5 +
> kernel/sched/core.c | 3 +
> kernel/sched/fair.c | 451 ++++++++++++++++++++++++------------------
> kernel/sched/pelt.h | 4 +-
> kernel/sched/sched.h | 7 +-
> 5 files changed, 274 insertions(+), 196 deletions(-)
That's very tiny overall in the scheme of what we take for the stable
trees.
> And a few more fixes that will add to the above before v6.18. I'll defer
> to Peter to decide the best course of action.
We'll defer to the maintainers of the subsystem as to what they want
here. If they say take this smaller patch, we'll be glad to do so.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-10-15 7:27 ` Greg Kroah-Hartman
@ 2025-10-15 8:22 ` Peter Zijlstra
0 siblings, 0 replies; 14+ messages in thread
From: Peter Zijlstra @ 2025-10-15 8:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: K Prateek Nayak, Sasha Levin, stable, Matt Fleming, Ingo Molnar,
Juri Lelli, Vincent Guittot, linux-kernel, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
kernel-team, Matt Fleming, Oleg Nesterov, John Stultz,
Chris Arges
On Wed, Oct 15, 2025 at 09:27:53AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 15, 2025 at 11:57:19AM +0530, K Prateek Nayak wrote:
> > Hello Greg,
> >
> > On 10/15/2025 11:44 AM, Greg Kroah-Hartman wrote:
> > >> Greg, Sasha,
> > >>
> > >> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
> > >> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
> > >> know if you would like me to send a seperate patch for each.
> > >>
> > >> As mentioned above, the upstream fixes this as a part of larger feature
> > >> and we would only like these bits backported. If there are any future
> > >> conflicts in this area during backporting, I would be more than happy to
> > >> help out resolve them.
> > >
> > > Why not just backport all of the mainline changes instead? As I say a
> > > lot, whenever we do these "one off" changes, it's almost always wrong
> > > and causes problems over the years going forward as other changes around
> > > the same area can not be backported either.
> > >
> > > So please, try to just backport the original commits.
> >
> > Peter was in favor of backporting just the necessary bits in
> > https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
> >
> > Backporting the whole of per-task throttle feature is lot more heavy
> > handed with the core changes adding:
> >
> > include/linux/sched.h | 5 +
> > kernel/sched/core.c | 3 +
> > kernel/sched/fair.c | 451 ++++++++++++++++++++++++------------------
> > kernel/sched/pelt.h | 4 +-
> > kernel/sched/sched.h | 7 +-
> > 5 files changed, 274 insertions(+), 196 deletions(-)
>
> That's very tiny overall in the scheme of what we take for the stable
> trees.
>
> > And a few more fixes that will add to the above before v6.18. I'll defer
> > to Peter to decide the best course of action.
>
> We'll defer to the maintainers of the subsystem as to what they want
> here. If they say take this smaller patch, we'll be glad to do so.
So if the timing of all this would've been slightly different, I'd have
taken the smaller patch and routed it through sched/urgent in time for
the 6.17 release. And we'd not have had this discussion, but alas.
Also, while we're fairly confident in the task throttling rework, it is
somewhat invasive and hasn't seen widespread testing -- it is
conceivable there are performance issues.
So at this point I would really rather backport the smaller patch that
fixes the immediate bug.
Thanks!
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 6.17] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
2025-09-26 15:34 ` Matt Fleming
2025-09-29 3:53 ` K Prateek Nayak
2025-10-15 6:03 ` [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue K Prateek Nayak
@ 2025-10-23 4:03 ` K Prateek Nayak
2 siblings, 0 replies; 14+ messages in thread
From: K Prateek Nayak @ 2025-10-23 4:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin, stable, Matt Fleming,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
linux-kernel
Cc: Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, kernel-team, Matt Fleming, Oleg Nesterov,
John Stultz, Chris Arges, Luis Claudio R. Goncalves,
K Prateek Nayak
Dequeuing a fair task on a throttled hierarchy returns early on
encountering a throttled cfs_rq since the throttle path has already
dequeued the hierarchy above and has adjusted the h_nr_* accounting till
the root cfs_rq.
dequeue_entities() crucially misses calling __block_task() for delayed
tasks being dequeued on the throttled hierarchies, but this was mostly
harmless until commit b7ca5743a260 ("sched/core: Tweak
wait_task_inactive() to force dequeue sched_delayed tasks") since all
existing cases would re-enqueue the task if task_on_rq_queued() returned
true and the task would eventually be blocked at pick after the
hierarchy was unthrottled.
wait_task_inactive() is special as it expects the delayed task on
throttled hierarchy to reach the blocked state on dequeue but since
__block_task() is never called, task_on_rq_queued() continues to return
true. Furthermore, since the task is now off the hierarchy, the pick
never reaches it to fully block the task even after unthrottle leading
to wait_task_inactive() looping endlessly.
Remedy this by calling __block_task() if a delayed task is being
dequeued on a throttled hierarchy.
This fix is only required for stabled kernels implementing delay dequeue
(>= v6.12) before v6.18 since upstream commit e1fad12dcb66 ("sched/fair:
Switch to task based throttle model") indirectly fixes this by removing
the early return conditions in dequeue_entities() as part of the per-task
throttle feature.
Cc: stable@vger.kernel.org
Reported-by: Matt Fleming <matt@readmodwrite.com>
Closes: https://lore.kernel.org/all/20250925133310.1843863-1-matt@readmodwrite.com/
Fixes: b7ca5743a260 ("sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks")
Tested-by: Matt Fleming <mfleming@cloudflare.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
Hello Greg, Sasha,
Please consider the same fix for the v6.17 stable kernel too since there
is a report of a similar issue on v6.17.1 based RT kernel at
https://lore.kernel.org/lkml/aPN7XBJbGhdWJDb2@uudg.org/ and Luis
confirmed that this fix solves the issue for him in
https://lore.kernel.org/lkml/aPgm6KvDx5Os2oJS@uudg.org/
---
kernel/sched/fair.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8ce56a8d507f..f0a4d9d7424d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6969,6 +6969,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
int h_nr_runnable = 0;
struct cfs_rq *cfs_rq;
u64 slice = 0;
+ int ret = 0;
if (entity_is_task(se)) {
p = task_of(se);
@@ -6998,7 +6999,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
/* end evaluation on encountering a throttled cfs_rq */
if (cfs_rq_throttled(cfs_rq))
- return 0;
+ goto out;
/* Don't dequeue parent if it has other entities besides us */
if (cfs_rq->load.weight) {
@@ -7039,7 +7040,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
/* end evaluation on encountering a throttled cfs_rq */
if (cfs_rq_throttled(cfs_rq))
- return 0;
+ goto out;
}
sub_nr_running(rq, h_nr_queued);
@@ -7048,6 +7049,8 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
rq->next_balance = jiffies;
+ ret = 1;
+out:
if (p && task_delayed) {
WARN_ON_ONCE(!task_sleep);
WARN_ON_ONCE(p->on_rq != 1);
@@ -7063,7 +7066,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
__block_task(rq, p);
}
- return 1;
+ return ret;
}
/*
base-commit: 6c7871823908a4330e145d635371582f76ce1407
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread