Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1576359 > unrolled thread

[RFC,v2 2/3] sched: set number of iterations to h_nr_running

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC,v2 2/3] sched: set number of iterations to h_nr_running Uladzislau Rezki <urezki@gmail.com> - 2017-02-08 10:00 +0100
    Re: [RFC,v2 2/3] sched: set number of iterations to h_nr_running Peter Zijlstra <peterz@infradead.org> - 2017-02-09 14:40 +0100
      Re: [RFC,v2 2/3] sched: set number of iterations to h_nr_running Uladzislau Rezki <urezki@gmail.com> - 2017-02-09 20:10 +0100

#1576359 — [RFC,v2 2/3] sched: set number of iterations to h_nr_running

From: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>

It is possible that busiest run queue has multiple RT tasks,
whereas no CFS tasks, that is why it is reasonable to use
h_nr_running instead, because a load balance only applies
for CFS related tasks.

Signed-off-by: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4be7193..232ef3c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8081,7 +8081,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
 		 * Set loop_max when rq's lock is taken to prevent a race.
 		 */
 		env.loop_max = min(sysctl_sched_nr_migrate,
-						busiest->nr_running);
+						busiest->cfs.h_nr_running);
 
 		/*
 		 * cur_ld_moved - load moved in current iteration
-- 
2.1.4

[toc] | [next] | [standalone]

#1577599

On Wed, Feb 08, 2017 at 09:43:28AM +0100, Uladzislau Rezki wrote:
> From: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
> 
> It is possible that busiest run queue has multiple RT tasks,
> whereas no CFS tasks, that is why it is reasonable to use
> h_nr_running instead, because a load balance only applies
> for CFS related tasks.

Sure, I suppose that makes sense, but then it would make even more sense
to do a more thorough audit of the code and make sure all remaining
rq::nr_running uses are correct.

[toc] | [prev] | [next] | [standalone]

#1577874

On Thu, Feb 9, 2017 at 1:20 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Feb 08, 2017 at 09:43:28AM +0100, Uladzislau Rezki wrote:
>> From: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
>>
>> It is possible that busiest run queue has multiple RT tasks,
>> whereas no CFS tasks, that is why it is reasonable to use
>> h_nr_running instead, because a load balance only applies
>> for CFS related tasks.
>

>
> Sure, I suppose that makes sense, but then it would make even more sense
> to do a more thorough audit of the code and make sure all remaining
> rq::nr_running uses are correct.
>
Indeed. I did not want to touch othe places, due to my specific test case.
There are still a few raming places. I can prepare a new patch that covers
all of them if that is ok.

-- 
Uladzislau Rezki

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web