Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

Hello.

Let's decide how to proceed with https://lkml.org/lkml/2017/2/14/334 patch.
Despite it is not a big change, i think it is important and ready to
be submited,
unless there are still any comments.

--
Uladzislau Rezki

On Thu, Feb 16, 2017 at 12:20 PM, Uladzislau Rezki  wrote:
> On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann
>  wrote:
>> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:
>
>
> So that is useful information that should have been in the Changelog.
>
> OK, can you respin this patch with adjusted Changelog and taking Mike's
> feedback?
>
 Yes, i will prepare a patch accordingly, no problem.

>
> Also, I worry about the effects of this on !PREEMPT kernels, the first
> hunk (which explicitly states is about latency) should be under
> CONFIG_PREEMPT to match the similar case we already have in
> detach_tasks().
>>
>>
>> This one uses #ifdef CONFIG_PREEMPT whereas you use
>> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?
>>
> I just wanted to put it under one line instead of using #ifdefs in my
> second hunk,
> so that is a matter of taste. Also, please find below different
> variants of how it can be
> rewriten:
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE)
> #endif
> if ((load / 2) > env->imbalance)
> goto next;
> 
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE &&
> (load / 2) > env->imbalance)
> goto next;
> #else
> if ((load / 2) > env->imbalance)
> goto next;
> #endif
> 
>
> If somebody has any preferences or concerns, please comment, i will
> re-spin the patch.
>
> --
> Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

Hello.

Let's decide how to proceed with https://lkml.org/lkml/2017/2/14/334 patch.
Despite it is not a big change, i think it is important and ready to
be submited,
unless there are still any comments.

--
Uladzislau Rezki

On Thu, Feb 16, 2017 at 12:20 PM, Uladzislau Rezki  wrote:
> On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann
>  wrote:
>> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:
>
>
> So that is useful information that should have been in the Changelog.
>
> OK, can you respin this patch with adjusted Changelog and taking Mike's
> feedback?
>
 Yes, i will prepare a patch accordingly, no problem.

>
> Also, I worry about the effects of this on !PREEMPT kernels, the first
> hunk (which explicitly states is about latency) should be under
> CONFIG_PREEMPT to match the similar case we already have in
> detach_tasks().
>>
>>
>> This one uses #ifdef CONFIG_PREEMPT whereas you use
>> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?
>>
> I just wanted to put it under one line instead of using #ifdefs in my
> second hunk,
> so that is a matter of taste. Also, please find below different
> variants of how it can be
> rewriten:
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE)
> #endif
> if ((load / 2) > env->imbalance)
> goto next;
> 
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE &&
> (load / 2) > env->imbalance)
> goto next;
> #else
> if ((load / 2) > env->imbalance)
> goto next;
> #endif
> 
>
> If somebody has any preferences or concerns, please comment, i will
> re-spin the patch.
>
> --
> Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann
 wrote:
> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:


 So that is useful information that should have been in the Changelog.

 OK, can you respin this patch with adjusted Changelog and taking Mike's
 feedback?

>>> Yes, i will prepare a patch accordingly, no problem.
>>>

 Also, I worry about the effects of this on !PREEMPT kernels, the first
 hunk (which explicitly states is about latency) should be under
 CONFIG_PREEMPT to match the similar case we already have in
 detach_tasks().
>
>
> This one uses #ifdef CONFIG_PREEMPT whereas you use
> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?
>
I just wanted to put it under one line instead of using #ifdefs in my
second hunk,
so that is a matter of taste. Also, please find below different
variants of how it can be
rewriten:


#ifdef CONFIG_PREEMPT
if (env->idle != CPU_NEWLY_IDLE)
#endif
if ((load / 2) > env->imbalance)
goto next;



#ifdef CONFIG_PREEMPT
if (env->idle != CPU_NEWLY_IDLE &&
(load / 2) > env->imbalance)
goto next;
#else
if ((load / 2) > env->imbalance)
goto next;
#endif


If somebody has any preferences or concerns, please comment, i will
re-spin the patch.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann
 wrote:
> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:


 So that is useful information that should have been in the Changelog.

 OK, can you respin this patch with adjusted Changelog and taking Mike's
 feedback?

>>> Yes, i will prepare a patch accordingly, no problem.
>>>

 Also, I worry about the effects of this on !PREEMPT kernels, the first
 hunk (which explicitly states is about latency) should be under
 CONFIG_PREEMPT to match the similar case we already have in
 detach_tasks().
>
>
> This one uses #ifdef CONFIG_PREEMPT whereas you use
> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?
>
I just wanted to put it under one line instead of using #ifdefs in my
second hunk,
so that is a matter of taste. Also, please find below different
variants of how it can be
rewriten:


#ifdef CONFIG_PREEMPT
if (env->idle != CPU_NEWLY_IDLE)
#endif
if ((load / 2) > env->imbalance)
goto next;



#ifdef CONFIG_PREEMPT
if (env->idle != CPU_NEWLY_IDLE &&
(load / 2) > env->imbalance)
goto next;
#else
if ((load / 2) > env->imbalance)
goto next;
#endif


If somebody has any preferences or concerns, please comment, i will
re-spin the patch.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Dietmar Eggemann]

On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:


So that is useful information that should have been in the Changelog.

OK, can you respin this patch with adjusted Changelog and taking Mike's
feedback?


Yes, i will prepare a patch accordingly, no problem.



Also, I worry about the effects of this on !PREEMPT kernels, the first
hunk (which explicitly states is about latency) should be under
CONFIG_PREEMPT to match the similar case we already have in
detach_tasks().


This one uses #ifdef CONFIG_PREEMPT whereas you use 
IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?



But your second hunk, which ignores the actual load of tasks in favour
of just moving _something_ already, is utterly dangerous if not coupled
with these two other conditions, so arguably that too should be under
CONFIG_PREEMPT.


I see your point. Will round both with CONFIG_PREEMPT.


I have upload a new patch, please find it here:
https://lkml.org/lkml/2017/2/14/334

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Dietmar Eggemann]

On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:


So that is useful information that should have been in the Changelog.

OK, can you respin this patch with adjusted Changelog and taking Mike's
feedback?


Yes, i will prepare a patch accordingly, no problem.



Also, I worry about the effects of this on !PREEMPT kernels, the first
hunk (which explicitly states is about latency) should be under
CONFIG_PREEMPT to match the similar case we already have in
detach_tasks().


This one uses #ifdef CONFIG_PREEMPT whereas you use 
IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?



But your second hunk, which ignores the actual load of tasks in favour
of just moving _something_ already, is utterly dangerous if not coupled
with these two other conditions, so arguably that too should be under
CONFIG_PREEMPT.


I see your point. Will round both with CONFIG_PREEMPT.


I have upload a new patch, please find it here:
https://lkml.org/lkml/2017/2/14/334

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

>>
>> So that is useful information that should have been in the Changelog.
>>
>> OK, can you respin this patch with adjusted Changelog and taking Mike's
>> feedback?
>>
> Yes, i will prepare a patch accordingly, no problem.
>
>>
>> Also, I worry about the effects of this on !PREEMPT kernels, the first
>> hunk (which explicitly states is about latency) should be under
>> CONFIG_PREEMPT to match the similar case we already have in
>> detach_tasks().
>>
>> But your second hunk, which ignores the actual load of tasks in favour
>> of just moving _something_ already, is utterly dangerous if not coupled
>> with these two other conditions, so arguably that too should be under
>> CONFIG_PREEMPT.
>>
> I see your point. Will round both with CONFIG_PREEMPT.
>
I have upload a new patch, please find it here:
https://lkml.org/lkml/2017/2/14/334

-- 
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

>>
>> So that is useful information that should have been in the Changelog.
>>
>> OK, can you respin this patch with adjusted Changelog and taking Mike's
>> feedback?
>>
> Yes, i will prepare a patch accordingly, no problem.
>
>>
>> Also, I worry about the effects of this on !PREEMPT kernels, the first
>> hunk (which explicitly states is about latency) should be under
>> CONFIG_PREEMPT to match the similar case we already have in
>> detach_tasks().
>>
>> But your second hunk, which ignores the actual load of tasks in favour
>> of just moving _something_ already, is utterly dangerous if not coupled
>> with these two other conditions, so arguably that too should be under
>> CONFIG_PREEMPT.
>>
> I see your point. Will round both with CONFIG_PREEMPT.
>
I have upload a new patch, please find it here:
https://lkml.org/lkml/2017/2/14/334

-- 
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Mon, Feb 13, 2017 at 2:51 PM, Peter Zijlstra  wrote:
> On Thu, Feb 09, 2017 at 07:54:05PM +0100, Uladzislau Rezki wrote:
>
>> > Does this patch make an actual difference, if so how much and with
>> > what workload?
>> >
>> Yes, it does. I see a slight improvement when it comes to frame drops
>> (in my case drops per/two seconds). Basically a test case is left finger
>> swipe on the display (21 times, duration is 2 seconds + 1 second sleep
>> between iterations):
>>
>> 0   Framedrops:  75
>> 1   Framedrops:  53
>> 2   Framedrops:  85
>> 3   Framedrops:  45
>> 4   Framedrops:  33
>> 5   Framedrops:  64
>> 6   Framedrops:  32
>> 7   Framedrops:  34
>> 8   Framedrops:  53
>> 9   Framedrops:  33
>> 10 Framedrops:  74
>> 11 Framedrops:  34
>> 12 Framedrops:  33
>> 13 Framedrops:  33
>> 14 Framedrops:  35
>> 15 Framedrops:  73
>> 16 Framedrops:  53
>> 17 Framedrops:  32
>> 18 Framedrops:  53
>> 19 Framedrops:  43
>> 20 Framedrops:  32
>>
>> max is 8 vs 5; min is 2 vs 3.
>>
>> As for applied load, it is not significant and i would say is "light".
>
> So that is useful information that should have been in the Changelog.
>
> OK, can you respin this patch with adjusted Changelog and taking Mike's
> feedback?
>
Yes, i will prepare a patch accordingly, no problem.

>
> Also, I worry about the effects of this on !PREEMPT kernels, the first
> hunk (which explicitly states is about latency) should be under
> CONFIG_PREEMPT to match the similar case we already have in
> detach_tasks().
>
> But your second hunk, which ignores the actual load of tasks in favour
> of just moving _something_ already, is utterly dangerous if not coupled
> with these two other conditions, so arguably that too should be under
> CONFIG_PREEMPT.
>
I see your point. Will round both with CONFIG_PREEMPT.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Mon, Feb 13, 2017 at 2:51 PM, Peter Zijlstra  wrote:
> On Thu, Feb 09, 2017 at 07:54:05PM +0100, Uladzislau Rezki wrote:
>
>> > Does this patch make an actual difference, if so how much and with
>> > what workload?
>> >
>> Yes, it does. I see a slight improvement when it comes to frame drops
>> (in my case drops per/two seconds). Basically a test case is left finger
>> swipe on the display (21 times, duration is 2 seconds + 1 second sleep
>> between iterations):
>>
>> 0   Framedrops:  75
>> 1   Framedrops:  53
>> 2   Framedrops:  85
>> 3   Framedrops:  45
>> 4   Framedrops:  33
>> 5   Framedrops:  64
>> 6   Framedrops:  32
>> 7   Framedrops:  34
>> 8   Framedrops:  53
>> 9   Framedrops:  33
>> 10 Framedrops:  74
>> 11 Framedrops:  34
>> 12 Framedrops:  33
>> 13 Framedrops:  33
>> 14 Framedrops:  35
>> 15 Framedrops:  73
>> 16 Framedrops:  53
>> 17 Framedrops:  32
>> 18 Framedrops:  53
>> 19 Framedrops:  43
>> 20 Framedrops:  32
>>
>> max is 8 vs 5; min is 2 vs 3.
>>
>> As for applied load, it is not significant and i would say is "light".
>
> So that is useful information that should have been in the Changelog.
>
> OK, can you respin this patch with adjusted Changelog and taking Mike's
> feedback?
>
Yes, i will prepare a patch accordingly, no problem.

>
> Also, I worry about the effects of this on !PREEMPT kernels, the first
> hunk (which explicitly states is about latency) should be under
> CONFIG_PREEMPT to match the similar case we already have in
> detach_tasks().
>
> But your second hunk, which ignores the actual load of tasks in favour
> of just moving _something_ already, is utterly dangerous if not coupled
> with these two other conditions, so arguably that too should be under
> CONFIG_PREEMPT.
>
I see your point. Will round both with CONFIG_PREEMPT.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Peter Zijlstra]

On Thu, Feb 09, 2017 at 07:54:05PM +0100, Uladzislau Rezki wrote:

> > Does this patch make an actual difference, if so how much and with
> > what workload?
> >
> Yes, it does. I see a slight improvement when it comes to frame drops
> (in my case drops per/two seconds). Basically a test case is left finger
> swipe on the display (21 times, duration is 2 seconds + 1 second sleep
> between iterations):
> 
> 0   Framedrops:  75
> 1   Framedrops:  53
> 2   Framedrops:  85
> 3   Framedrops:  45
> 4   Framedrops:  33
> 5   Framedrops:  64
> 6   Framedrops:  32
> 7   Framedrops:  34
> 8   Framedrops:  53
> 9   Framedrops:  33
> 10 Framedrops:  74
> 11 Framedrops:  34
> 12 Framedrops:  33
> 13 Framedrops:  33
> 14 Framedrops:  35
> 15 Framedrops:  73
> 16 Framedrops:  53
> 17 Framedrops:  32
> 18 Framedrops:  53
> 19 Framedrops:  43
> 20 Framedrops:  32
> 
> max is 8 vs 5; min is 2 vs 3.
> 
> As for applied load, it is not significant and i would say is "light".

So that is useful information that should have been in the Changelog.

OK, can you respin this patch with adjusted Changelog and taking Mike's
feedback?

Also, I worry about the effects of this on !PREEMPT kernels, the first
hunk (which explicitly states is about latency) should be under
CONFIG_PREEMPT to match the similar case we already have in
detach_tasks().

But your second hunk, which ignores the actual load of tasks in favour
of just moving _something_ already, is utterly dangerous if not coupled
with these two other conditions, so arguably that too should be under
CONFIG_PREEMPT.

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Peter Zijlstra]

On Thu, Feb 09, 2017 at 07:54:05PM +0100, Uladzislau Rezki wrote:

> > Does this patch make an actual difference, if so how much and with
> > what workload?
> >
> Yes, it does. I see a slight improvement when it comes to frame drops
> (in my case drops per/two seconds). Basically a test case is left finger
> swipe on the display (21 times, duration is 2 seconds + 1 second sleep
> between iterations):
> 
> 0   Framedrops:  75
> 1   Framedrops:  53
> 2   Framedrops:  85
> 3   Framedrops:  45
> 4   Framedrops:  33
> 5   Framedrops:  64
> 6   Framedrops:  32
> 7   Framedrops:  34
> 8   Framedrops:  53
> 9   Framedrops:  33
> 10 Framedrops:  74
> 11 Framedrops:  34
> 12 Framedrops:  33
> 13 Framedrops:  33
> 14 Framedrops:  35
> 15 Framedrops:  73
> 16 Framedrops:  53
> 17 Framedrops:  32
> 18 Framedrops:  53
> 19 Framedrops:  43
> 20 Framedrops:  32
> 
> max is 8 vs 5; min is 2 vs 3.
> 
> As for applied load, it is not significant and i would say is "light".

So that is useful information that should have been in the Changelog.

OK, can you respin this patch with adjusted Changelog and taking Mike's
feedback?

Also, I worry about the effects of this on !PREEMPT kernels, the first
hunk (which explicitly states is about latency) should be under
CONFIG_PREEMPT to match the similar case we already have in
detach_tasks().

But your second hunk, which ignores the actual load of tasks in favour
of just moving _something_ already, is utterly dangerous if not coupled
with these two other conditions, so arguably that too should be under
CONFIG_PREEMPT.

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Thu, Feb 9, 2017 at 1:22 PM, Peter Zijlstra  wrote:
> On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote:
>> From: Uladzislau 2 Rezki 
>>
>> A load balancer calculates imbalance factor for particular shed
>> domain and tries to steal up the prescribed amount of weighted load.
>> However, a small imbalance factor would sometimes prevent us from
>> stealing any tasks at all. When a CPU is newly idle, it should
>> steal first task which passes a migration criteria.
>>

>
> So ideally we'd reduce the number of special cases instead of increase
> them.
>
I agree.

>
> Does this patch make an actual difference, if so how much and with
> what workload?
>
Yes, it does. I see a slight improvement when it comes to frame drops
(in my case drops per/two seconds). Basically a test case is left finger
swipe on the display (21 times, duration is 2 seconds + 1 second sleep
between iterations):

0   Framedrops:  75
1   Framedrops:  53
2   Framedrops:  85
3   Framedrops:  45
4   Framedrops:  33
5   Framedrops:  64
6   Framedrops:  32
7   Framedrops:  34
8   Framedrops:  53
9   Framedrops:  33
10 Framedrops:  74
11 Framedrops:  34
12 Framedrops:  33
13 Framedrops:  33
14 Framedrops:  35
15 Framedrops:  73
16 Framedrops:  53
17 Framedrops:  32
18 Framedrops:  53
19 Framedrops:  43
20 Framedrops:  32

max is 8 vs 5; min is 2 vs 3.

As for applied load, it is not significant and i would say is "light".

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

On Thu, Feb 9, 2017 at 1:22 PM, Peter Zijlstra  wrote:
> On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote:
>> From: Uladzislau 2 Rezki 
>>
>> A load balancer calculates imbalance factor for particular shed
>> domain and tries to steal up the prescribed amount of weighted load.
>> However, a small imbalance factor would sometimes prevent us from
>> stealing any tasks at all. When a CPU is newly idle, it should
>> steal first task which passes a migration criteria.
>>

>
> So ideally we'd reduce the number of special cases instead of increase
> them.
>
I agree.

>
> Does this patch make an actual difference, if so how much and with
> what workload?
>
Yes, it does. I see a slight improvement when it comes to frame drops
(in my case drops per/two seconds). Basically a test case is left finger
swipe on the display (21 times, duration is 2 seconds + 1 second sleep
between iterations):

0   Framedrops:  75
1   Framedrops:  53
2   Framedrops:  85
3   Framedrops:  45
4   Framedrops:  33
5   Framedrops:  64
6   Framedrops:  32
7   Framedrops:  34
8   Framedrops:  53
9   Framedrops:  33
10 Framedrops:  74
11 Framedrops:  34
12 Framedrops:  33
13 Framedrops:  33
14 Framedrops:  35
15 Framedrops:  73
16 Framedrops:  53
17 Framedrops:  32
18 Framedrops:  53
19 Framedrops:  43
20 Framedrops:  32

max is 8 vs 5; min is 2 vs 3.

As for applied load, it is not significant and i would say is "light".

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Peter Zijlstra]

On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote:
> From: Uladzislau 2 Rezki 
> 
> A load balancer calculates imbalance factor for particular shed
> domain and tries to steal up the prescribed amount of weighted load.
> However, a small imbalance factor would sometimes prevent us from
> stealing any tasks at all. When a CPU is newly idle, it should
> steal first task which passes a migration criteria.
> 

So ideally we'd reduce the number of special cases instead of increase
them. Does this patch make an actual difference, if so how much and with
what workload?

Also, I suppose that if we finally manage to parameterize the whole
load-balancing to act on: nr_running/util/load depending on the domain
this all naturally falls into place.

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Peter Zijlstra]

On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote:
> From: Uladzislau 2 Rezki 
> 
> A load balancer calculates imbalance factor for particular shed
> domain and tries to steal up the prescribed amount of weighted load.
> However, a small imbalance factor would sometimes prevent us from
> stealing any tasks at all. When a CPU is newly idle, it should
> steal first task which passes a migration criteria.
> 

So ideally we'd reduce the number of special cases instead of increase
them. Does this patch make an actual difference, if so how much and with
what workload?

Also, I suppose that if we finally manage to parameterize the whole
load-balancing to act on: nr_running/util/load depending on the domain
this all naturally falls into place.

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

>
> On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote:
> > From: Uladzislau 2 Rezki 
> >
> > A load balancer calculates imbalance factor for particular shed
>  ^sched
Will fix that.

> > domain and tries to steal up the prescribed amount of weighted load.
> > However, a small imbalance factor would sometimes prevent us from
> > stealing any tasks at all. When a CPU is newly idle, it should
> > steal first task which passes a migration criteria.
>  s/passes a/meets the
Will change the description.

> >
> > Signed-off-by: Uladzislau 2 Rezki 
> > ---
> >  kernel/sched/fair.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 232ef3c..29e0d7f 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> >   >   > env->loop++;
> > @@ -6824,8 +6832,9 @@ static int detach_tasks(struct lb_env *env)
> >  >>   > if (sched_feat(LB_MIN) && load < 16 && 
> > !env->sd->nr_balance_failed)
> >  >>   >   > goto next;
> >
> > ->>   > if ((load / 2) > env->imbalance)
> > ->>   >   > goto next;
> > +>>   > if (env->idle != CPU_NEWLY_IDLE)
> > +>>   >   > if ((load / 2) > env->imbalance)
> > +>>   >   >   > goto next;
>
> Those two ifs could be one ala if (foo && bar).
Agree.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

>
> On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote:
> > From: Uladzislau 2 Rezki 
> >
> > A load balancer calculates imbalance factor for particular shed
>  ^sched
Will fix that.

> > domain and tries to steal up the prescribed amount of weighted load.
> > However, a small imbalance factor would sometimes prevent us from
> > stealing any tasks at all. When a CPU is newly idle, it should
> > steal first task which passes a migration criteria.
>  s/passes a/meets the
Will change the description.

> >
> > Signed-off-by: Uladzislau 2 Rezki 
> > ---
> >  kernel/sched/fair.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 232ef3c..29e0d7f 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> >   >   > env->loop++;
> > @@ -6824,8 +6832,9 @@ static int detach_tasks(struct lb_env *env)
> >  >>   > if (sched_feat(LB_MIN) && load < 16 && 
> > !env->sd->nr_balance_failed)
> >  >>   >   > goto next;
> >
> > ->>   > if ((load / 2) > env->imbalance)
> > ->>   >   > goto next;
> > +>>   > if (env->idle != CPU_NEWLY_IDLE)
> > +>>   >   > if ((load / 2) > env->imbalance)
> > +>>   >   >   > goto next;
>
> Those two ifs could be one ala if (foo && bar).
Agree.

--
Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Mike Galbraith]

On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote:
> From: Uladzislau 2 Rezki 
> 
> A load balancer calculates imbalance factor for particular shed
 ^sched
> domain and tries to steal up the prescribed amount of weighted load.
> However, a small imbalance factor would sometimes prevent us from
> stealing any tasks at all. When a CPU is newly idle, it should
> steal first task which passes a migration criteria.
 s/passes a/meets the
> 
> Signed-off-by: Uladzislau 2 Rezki 
> ---
>  kernel/sched/fair.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 232ef3c..29e0d7f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
>   >   > env->loop++;
> @@ -6824,8 +6832,9 @@ static int detach_tasks(struct lb_env *env)
>  >>   > if (sched_feat(LB_MIN) && load < 16 && 
> !env->sd->nr_balance_failed)
>  >>   >   > goto next;
>  
> ->>   > if ((load / 2) > env->imbalance)
> ->>   >   > goto next;
> +>>   > if (env->idle != CPU_NEWLY_IDLE)
> +>>   >   > if ((load / 2) > env->imbalance)
> +>>   >   >   > goto next;

Those two ifs could be one ala if (foo && bar).

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Mike Galbraith]

On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote:
> From: Uladzislau 2 Rezki 
> 
> A load balancer calculates imbalance factor for particular shed
 ^sched
> domain and tries to steal up the prescribed amount of weighted load.
> However, a small imbalance factor would sometimes prevent us from
> stealing any tasks at all. When a CPU is newly idle, it should
> steal first task which passes a migration criteria.
 s/passes a/meets the
> 
> Signed-off-by: Uladzislau 2 Rezki 
> ---
>  kernel/sched/fair.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 232ef3c..29e0d7f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
>   >   > env->loop++;
> @@ -6824,8 +6832,9 @@ static int detach_tasks(struct lb_env *env)
>  >>   > if (sched_feat(LB_MIN) && load < 16 && 
> !env->sd->nr_balance_failed)
>  >>   >   > goto next;
>  
> ->>   > if ((load / 2) > env->imbalance)
> ->>   >   > goto next;
> +>>   > if (env->idle != CPU_NEWLY_IDLE)
> +>>   >   > if ((load / 2) > env->imbalance)
> +>>   >   >   > goto next;

Those two ifs could be one ala if (foo && bar).