Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp656507ybb; Fri, 20 Mar 2020 06:00:20 -0700 (PDT) X-Google-Smtp-Source: ADFU+vufPbb5DiSeMOYi6hqGy79XR34vIsQqark83uMhjoNqR2S3y2sfYe6lvFuhUZzFIMFziJQM X-Received: by 2002:aca:dc45:: with SMTP id t66mr6395357oig.39.1584709220555; Fri, 20 Mar 2020 06:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584709220; cv=none; d=google.com; s=arc-20160816; b=TeRVsO4YTySCbsQC07EJowxxCUa78mu6XodGPAZLSBsd4X8QrM8UUh3GaneKvvrPtP e+BAh708U7pQmhses/ut20BDKbCLBmioEQ/CHq+v0+S4G4YO/GjBu5RKbwbOOvkzCqsO CkHl1NT6SBW1EtOc4OcjbF7afTKqPSakET9NpRT/JzMWKem30km6Lv/2chJ+tfuCmSjH MZHeJO5vGYMPfkeQpMnehOlr3n3412MPHKVRBWWB+wVDMU4Fwag3Amg0EYTjAi/ZaHFM c+Vr3mT/yGm+6wNEE2dUQDI8xXvKoJFETcqvVBGlYh51D9WcclQ+Gzmr+c+mKAyQe+Z4 2tmg== 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 :robot-unsubscribe:robot-id:message-id:mime-version:references :in-reply-to:cc:subject:to:reply-to:from:date; bh=CH2HDuGzTtgYlpvT5vKFovaxOQm8Dca53tuYmSi9Vgw=; b=VBoKZ6q4eHsmtcZh0zkrVkHcD9Xk3SF2+2FydGrRkyS1uhQL+e6FPvPkBWs9Xuc11m U5fut6HApey3g7HFbamu3+vwUBRnrdbRV50N9bAyPN1r6OKy/LvVReloSoWWnsoVyyoz JKJL18RX6ZK/w/rUre/mc9ijVUOunO83jZ8nbBz8YZbbGIugSY36NltEKSeOUQeLG900 PIUcvzLasVaKdMj9zxWxFgcXtD/+JzQkBe6nTVA8YYZ9jdP7L6WJghPJ1Q/wnsx7MTzm r7ktS/jJgkz1eVBh2EyfJ4Tafwkq0ioMHhLQw/f9h7ftpjx1CtWZHxeQ8QAoFrqylJvY XDGg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i23si456761otk.211.2020.03.20.06.00.08; Fri, 20 Mar 2020 06:00:20 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727428AbgCTM6i (ORCPT + 99 others); Fri, 20 Mar 2020 08:58:38 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:35650 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727289AbgCTM6S (ORCPT ); Fri, 20 Mar 2020 08:58:18 -0400 Received: from [5.158.153.53] (helo=tip-bot2.lab.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jFHE1-0003ik-TQ; Fri, 20 Mar 2020 13:58:09 +0100 Received: from [127.0.1.1] (localhost [IPv6:::1]) by tip-bot2.lab.linutronix.de (Postfix) with ESMTP id 7F7301C22BE; Fri, 20 Mar 2020 13:58:04 +0100 (CET) Date: Fri, 20 Mar 2020 12:58:04 -0000 From: "tip-bot2 for Michael Wang" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched: Avoid scale real weight down to zero Cc: Peter Zijlstra , Michael Wang , Vincent Guittot , x86 , LKML In-Reply-To: <38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com> References: <38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com> MIME-Version: 1.0 Message-ID: <158470908420.28353.7458716356925750750.tip-bot2@tip-bot2> X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the sched/core branch of tip: Commit-ID: 26cf52229efc87e2effa9d788f9b33c40fb3358a Gitweb: https://git.kernel.org/tip/26cf52229efc87e2effa9d788f9b33c40fb3358a Author: Michael Wang AuthorDate: Wed, 18 Mar 2020 10:15:15 +08:00 Committer: Peter Zijlstra CommitterDate: Fri, 20 Mar 2020 13:06:19 +01:00 sched: Avoid scale real weight down to zero During our testing, we found a case that shares no longer working correctly, the cgroup topology is like: /sys/fs/cgroup/cpu/A (shares=102400) /sys/fs/cgroup/cpu/A/B (shares=2) /sys/fs/cgroup/cpu/A/B/C (shares=1024) /sys/fs/cgroup/cpu/D (shares=1024) /sys/fs/cgroup/cpu/D/E (shares=1024) /sys/fs/cgroup/cpu/D/E/F (shares=1024) The same benchmark is running in group C & F, no other tasks are running, the benchmark is capable to consumed all the CPUs. We suppose the group C will win more CPU resources since it could enjoy all the shares of group A, but it's F who wins much more. The reason is because we have group B with shares as 2, since A->cfs_rq.load.weight == B->se.load.weight == B->shares/nr_cpus, so A->cfs_rq.load.weight become very small. And in calc_group_shares() we calculate shares as: load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); shares = (tg_shares * load) / tg_weight; Since the 'cfs_rq->load.weight' is too small, the load become 0 after scale down, although 'tg_shares' is 102400, shares of the se which stand for group A on root cfs_rq become 2. While the se of D on root cfs_rq is far more bigger than 2, so it wins the battle. 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. Suggested-by: Peter Zijlstra Signed-off-by: Michael Wang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com --- 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 9e173fa..1e72d1b 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(2UL, __w >> SCHED_FIXEDPOINT_SHIFT); \ + __w; \ +}) #else # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT) # define scale_load(w) (w)