[PATCH] sched/fair: fix use stale overloaded status to find busiest group

[PATCH] sched/fair: fix use stale overloaded status to find busiest group

[Wanpeng Li]

Commit caeb178c60f4 ("sched/fair: Make update_sd_pick_busiest() return 
'true' on a busier sd") makes groups are ranked in the order overloaded > 
imbalance > other and busiest group is picked according to this order. 
sgs->group_capacity_factor is used to check if group is overloaded. In 
the case of the child domain prefers tasks go to siblings first, the 
sgs->group_capacity_factor will be set lower to one in order to move all 
the excess tasks away. However, group overloaded status is not updated 
in the case of sgs->group_capacity_factor be set lower to one which 
leads to miss find the busiest group. This patch fix it by updating 
group overloaded status in the case of sg capacity factor is set to 
one in order to find busiest group accurately.

Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
---
 kernel/sched/fair.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ec32c26d..c603e50 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6344,8 +6344,10 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
 		 * with a large weight task outweighs the tasks on the system).
 		 */
 		if (prefer_sibling && sds->local &&
-		    sds->local_stat.group_has_free_capacity)
+		    sds->local_stat.group_has_free_capacity) {
 			sgs->group_capacity_factor = min(sgs->group_capacity_factor, 1U);
+			sgs->group_type = group_classify(sg, sgs);
+		}
 
 		if (update_sd_pick_busiest(env, sds, sg, sgs)) {
 			sds->busiest = sg;
-- 
1.9.1

Re: [PATCH] sched/fair: fix use stale overloaded status to find busiest group

[Peter Zijlstra]

On Tue, Nov 04, 2014 at 01:30:56PM +0800, Wanpeng Li wrote:
> Commit caeb178c60f4 ("sched/fair: Make update_sd_pick_busiest() return 
> 'true' on a busier sd") makes groups are ranked in the order overloaded > 
> imbalance > other and busiest group is picked according to this order. 
> sgs->group_capacity_factor is used to check if group is overloaded. In 
> the case of the child domain prefers tasks go to siblings first, the 
> sgs->group_capacity_factor will be set lower to one in order to move all 
> the excess tasks away. However, group overloaded status is not updated 
> in the case of sgs->group_capacity_factor be set lower to one which 
> leads to miss find the busiest group. This patch fix it by updating 
> group overloaded status in the case of sg capacity factor is set to 
> one in order to find busiest group accurately.

You noticed this while going over Vincents patches, right?

Also, try and introduce some newlines in the changelog, paragraphs of
3-5 lines are best.

Re: [PATCH] sched/fair: fix use stale overloaded status to find busiest group

[Wanpeng Li]

Hi Peter,
On 14/11/4 下午6:52, Peter Zijlstra wrote:
> On Tue, Nov 04, 2014 at 01:30:56PM +0800, Wanpeng Li wrote:
>> Commit caeb178c60f4 ("sched/fair: Make update_sd_pick_busiest() return
>> 'true' on a busier sd") makes groups are ranked in the order overloaded >
>> imbalance > other and busiest group is picked according to this order.
>> sgs->group_capacity_factor is used to check if group is overloaded. In
>> the case of the child domain prefers tasks go to siblings first, the
>> sgs->group_capacity_factor will be set lower to one in order to move all
>> the excess tasks away. However, group overloaded status is not updated
>> in the case of sgs->group_capacity_factor be set lower to one which
>> leads to miss find the busiest group. This patch fix it by updating
>> group overloaded status in the case of sg capacity factor is set to
>> one in order to find busiest group accurately.
> You noticed this while going over Vincents patches, right?

Indeed. ;-)

>
> Also, try and introduce some newlines in the changelog, paragraphs of
> 3-5 lines are best.

Ok, I will send a new version tomorrow. ;-)

Regards,
Wanpeng Li

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/