* [PATCH] sched/fair: Optimize dequeue_task_fair()
@ 2020-06-15 14:16 Peng Wang
2020-06-15 15:09 ` Vincent Guittot
2020-06-16 6:04 ` [PATCH v2] " Peng Wang
0 siblings, 2 replies; 6+ messages in thread
From: Peng Wang @ 2020-06-15 14:16 UTC (permalink / raw)
To: mingo, peterz, juri.lelli, vincent.guittot, dietmar.eggemann,
rostedt, bsegall, mgorman
Cc: linux-kernel
While looking at enqueue_task_fair and dequeue_task_fair, it occurred
to me that dequeue_task_fair can also be optimized as Vincent described
in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
dequeue_throttle label can ensure se not to be NULL, and se is
always NULL when reaching root level.
Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
---
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index cbcb2f7..e6be952 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5614,10 +5614,10 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
}
-dequeue_throttle:
- if (!se)
- sub_nr_running(rq, 1);
+ /* At this point se is NULL and we are at root level*/
+ sub_nr_running(rq, 1);
+dequeue_throttle:
/* balance early to pull high priority tasks */
if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
rq->next_balance = jiffies;
--
2.9.5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] sched/fair: Optimize dequeue_task_fair()
2020-06-15 14:16 [PATCH] sched/fair: Optimize dequeue_task_fair() Peng Wang
@ 2020-06-15 15:09 ` Vincent Guittot
2020-06-16 6:09 ` Peng Wang
2020-06-16 6:04 ` [PATCH v2] " Peng Wang
1 sibling, 1 reply; 6+ messages in thread
From: Vincent Guittot @ 2020-06-15 15:09 UTC (permalink / raw)
To: Peng Wang
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel
On Mon, 15 Jun 2020 at 16:20, Peng Wang <rocking@linux.alibaba.com> wrote:
>
> While looking at enqueue_task_fair and dequeue_task_fair, it occurred
> to me that dequeue_task_fair can also be optimized as Vincent described
> in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
good point
>
> dequeue_throttle label can ensure se not to be NULL, and se is
> always NULL when reaching root level.
>
> Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
> ---
> kernel/sched/fair.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cbcb2f7..e6be952 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5614,10 +5614,10 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>
> }
>
> -dequeue_throttle:
> - if (!se)
> - sub_nr_running(rq, 1);
> + /* At this point se is NULL and we are at root level*/
> + sub_nr_running(rq, 1);
>
> +dequeue_throttle:
> /* balance early to pull high priority tasks */
> if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
> rq->next_balance = jiffies;
You can move the label here because sched_idle_rq() uses
rq->nr-running and rq->cfs.idle_h_nr_running so they will not change
if we jump to the label before reaching root level
> --
> 2.9.5
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] sched/fair: Optimize dequeue_task_fair()
2020-06-15 14:16 [PATCH] sched/fair: Optimize dequeue_task_fair() Peng Wang
2020-06-15 15:09 ` Vincent Guittot
@ 2020-06-16 6:04 ` Peng Wang
2020-06-16 12:31 ` Vincent Guittot
1 sibling, 1 reply; 6+ messages in thread
From: Peng Wang @ 2020-06-16 6:04 UTC (permalink / raw)
To: mingo, peterz, juri.lelli, vincent.guittot, dietmar.eggemann,
rostedt, bsegall, mgorman
Cc: linux-kernel
While looking at enqueue_task_fair and dequeue_task_fair, it occurred
to me that dequeue_task_fair can also be optimized as Vincent described
in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
When encountering throttled cfs_rq, dequeue_throttle label can ensure
se not to be NULL, and rq->nr_running remains unchanged, so we can also
skip the early balance check.
Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
---
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index cbcb2f7..05242b7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5614,14 +5614,14 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
}
-dequeue_throttle:
- if (!se)
- sub_nr_running(rq, 1);
+ /* At this point se is NULL and we are at root level*/
+ sub_nr_running(rq, 1);
/* balance early to pull high priority tasks */
if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
rq->next_balance = jiffies;
+dequeue_throttle:
util_est_dequeue(&rq->cfs, p, task_sleep);
hrtick_update(rq);
}
--
2.9.5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] sched/fair: Optimize dequeue_task_fair()
2020-06-15 15:09 ` Vincent Guittot
@ 2020-06-16 6:09 ` Peng Wang
0 siblings, 0 replies; 6+ messages in thread
From: Peng Wang @ 2020-06-16 6:09 UTC (permalink / raw)
To: Vincent Guittot
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel
On 6/15/20 11:09 PM, Vincent Guittot wrote:
> On Mon, 15 Jun 2020 at 16:20, Peng Wang <rocking@linux.alibaba.com> wrote:
>>
>> While looking at enqueue_task_fair and dequeue_task_fair, it occurred
>> to me that dequeue_task_fair can also be optimized as Vincent described
>> in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
>
> good point
>
>>
>> dequeue_throttle label can ensure se not to be NULL, and se is
>> always NULL when reaching root level.
>>
>> Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
>> ---
>> kernel/sched/fair.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index cbcb2f7..e6be952 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5614,10 +5614,10 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>>
>> }
>>
>> -dequeue_throttle:
>> - if (!se)
>> - sub_nr_running(rq, 1);
>> + /* At this point se is NULL and we are at root level*/
>> + sub_nr_running(rq, 1);
>>
>> +dequeue_throttle:
>> /* balance early to pull high priority tasks */
>> if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
>> rq->next_balance = jiffies;
>
> You can move the label here because sched_idle_rq() uses
> rq->nr-running and rq->cfs.idle_h_nr_running so they will not change
> if we jump to the label before reaching root level
Yes, then we can also skip the early balance check.
>
>> --
>> 2.9.5
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] sched/fair: Optimize dequeue_task_fair()
2020-06-16 6:04 ` [PATCH v2] " Peng Wang
@ 2020-06-16 12:31 ` Vincent Guittot
2020-06-16 13:38 ` Peter Zijlstra
0 siblings, 1 reply; 6+ messages in thread
From: Vincent Guittot @ 2020-06-16 12:31 UTC (permalink / raw)
To: Peng Wang
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel
On Tue, 16 Jun 2020 at 08:05, Peng Wang <rocking@linux.alibaba.com> wrote:
>
> While looking at enqueue_task_fair and dequeue_task_fair, it occurred
> to me that dequeue_task_fair can also be optimized as Vincent described
> in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
>
> When encountering throttled cfs_rq, dequeue_throttle label can ensure
> se not to be NULL, and rq->nr_running remains unchanged, so we can also
> skip the early balance check.
>
> Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cbcb2f7..05242b7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5614,14 +5614,14 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>
> }
>
> -dequeue_throttle:
> - if (!se)
> - sub_nr_running(rq, 1);
> + /* At this point se is NULL and we are at root level*/
> + sub_nr_running(rq, 1);
>
> /* balance early to pull high priority tasks */
> if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
> rq->next_balance = jiffies;
>
> +dequeue_throttle:
> util_est_dequeue(&rq->cfs, p, task_sleep);
> hrtick_update(rq);
> }
> --
> 2.9.5
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] sched/fair: Optimize dequeue_task_fair()
2020-06-16 12:31 ` Vincent Guittot
@ 2020-06-16 13:38 ` Peter Zijlstra
0 siblings, 0 replies; 6+ messages in thread
From: Peter Zijlstra @ 2020-06-16 13:38 UTC (permalink / raw)
To: Vincent Guittot
Cc: Peng Wang, Ingo Molnar, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel
On Tue, Jun 16, 2020 at 02:31:15PM +0200, Vincent Guittot wrote:
> On Tue, 16 Jun 2020 at 08:05, Peng Wang <rocking@linux.alibaba.com> wrote:
> >
> > While looking at enqueue_task_fair and dequeue_task_fair, it occurred
> > to me that dequeue_task_fair can also be optimized as Vincent described
> > in commit 7d148be69e3a ("sched/fair: Optimize enqueue_task_fair()").
> >
> > When encountering throttled cfs_rq, dequeue_throttle label can ensure
> > se not to be NULL, and rq->nr_running remains unchanged, so we can also
> > skip the early balance check.
> >
> > Signed-off-by: Peng Wang <rocking@linux.alibaba.com>
>
> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-16 13:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 14:16 [PATCH] sched/fair: Optimize dequeue_task_fair() Peng Wang
2020-06-15 15:09 ` Vincent Guittot
2020-06-16 6:09 ` Peng Wang
2020-06-16 6:04 ` [PATCH v2] " Peng Wang
2020-06-16 12:31 ` Vincent Guittot
2020-06-16 13:38 ` Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).