Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp95487ybh; Tue, 10 Mar 2020 20:12:40 -0700 (PDT) X-Google-Smtp-Source: ADFU+vv/Ch6a1S8uS1klese8BTEau7Vx2FvWyS4MiMY3dSSXzeUueMg+oGFA8nWidokTAtzG4zyS X-Received: by 2002:a05:6830:11c7:: with SMTP id v7mr653883otq.41.1583896360667; Tue, 10 Mar 2020 20:12:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583896360; cv=none; d=google.com; s=arc-20160816; b=GcECnurjMUhWPv0zNWTjM7IcTZsjGlzACiodA1PYsiei+g2GD6hAgw9GNylEWDlpiG IF8ZRmTATllYsx9811hEW361cf2I5+sNf7O9y4dxNfxF+t7vMIASMaBdyLqxahfJfTrR LWX+iyG7zzcF4ovvRbiUE4ifhtUec04ccpbGHrgn07dSNIPkw8/NtPIgZdRcd5e0N862 KC8E3318cDjW3aMv/i4DZgcykfR7CwxkdW7y3DS+GHuTwWvWLhqzSzNzZpTwmt/q+J2M CF4p4iZhfZsno2y0bg+0EKavsrvlz3POTxS/WSzyhd3uiZba6w/FtnMIJdoRum6a7pNd TZYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=xXN7qCil8p5aC3ud3rC/BgGKAKsZbvWSF07qR7tf4ps=; b=Xd+cXu+KtArdv+meLFLsXjRVw85fNoTatMZKOhmmAV7iJgozqNH8BIk8T2bT4PeYOA 1BULId8+fJqIfH2UyUmVWFSnUZHqVok2VfkD7ARej3tOducIitEjCoWhqfELBEJak/0I eqIwmyyVy/PqjxEtu7B7ycjpDLcR5FLkzzrklDb9aN8tHMY/8d+GkrDf9ofNFvL+oE4m cRAM+Mute9ZdkS3GiksijccCQ0aNajm7XSQlTuFlPO2DcxtozfdCujpYvADeJPQOD8j3 p1w1hl11Bu+mdEdkfFE3E/rAMl5nwu/oOefd017Q/zZjUXfqIKDtCJsbrrYoVvVbx80+ YVcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z2si400693oix.100.2020.03.10.20.12.27; Tue, 10 Mar 2020 20:12:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727659AbgCKDMM (ORCPT + 99 others); Tue, 10 Mar 2020 23:12:12 -0400 Received: from out30-131.freemail.mail.aliyun.com ([115.124.30.131]:54304 "EHLO out30-131.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727307AbgCKDMM (ORCPT ); Tue, 10 Mar 2020 23:12:12 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04397;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0TsGH4Kz_1583896327; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0TsGH4Kz_1583896327) by smtp.aliyun-inc.com(127.0.0.1); Wed, 11 Mar 2020 11:12:08 +0800 Subject: Re: [PATCH] sched: avoid scale real weight down to zero To: Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , "open list:SCHEDULER" References: From: =?UTF-8?B?546L6LSH?= Message-ID: <63631321-3e25-913e-a061-9ff65c98b76b@linux.alibaba.com> Date: Wed, 11 Mar 2020 11:12:07 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/3/6 下午11:06, Vincent Guittot wrote: [snip] >> >> Thus when scale_load_down() scale real weight down to 0, it's no >> longer telling the real story, the caller will have the wrong >> information and the calculation will be buggy. >> >> This patch add check in scale_load_down(), so the real weight will >> be >= MIN_SHARES after scale, after applied the group C wins as >> expected. >> >> Cc: Ben Segall >> Cc: Vincent Guittot >> Suggested-by: Peter Zijlstra >> Signed-off-by: Michael Wang > > Reviewed-by: Vincent Guittot Thanks for the review :-) Hi Peter, should we apply this one? Regards, Michael Wang >> --- >> kernel/sched/sched.h | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h >> index 2a0caf394dd4..75c283f22256 100644 >> --- a/kernel/sched/sched.h >> +++ b/kernel/sched/sched.h >> @@ -118,7 +118,13 @@ extern long calc_load_fold_active(struct rq *this_rq, long adjust); >> #ifdef CONFIG_64BIT >> # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + SCHED_FIXEDPOINT_SHIFT) >> # define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT) >> -# define scale_load_down(w) ((w) >> SCHED_FIXEDPOINT_SHIFT) >> +# define scale_load_down(w) \ >> +({ \ >> + unsigned long __w = (w); \ >> + if (__w) \ >> + __w = max(MIN_SHARES, __w >> SCHED_FIXEDPOINT_SHIFT); \ >> + __w; \ >> +}) >> #else >> # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT) >> # define scale_load(w) (w) >> -- >> 2.14.4.44.g2045bb6 >>