Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7506451ybl; Tue, 24 Dec 2019 03:56:21 -0800 (PST) X-Google-Smtp-Source: APXvYqwYrdsm2xl3drla7gEFM8oiKu40YZjndSuMD5qXXoufEJByHSxSSLYbhdsJ6MSdJt0eDhVY X-Received: by 2002:a05:6830:3c5:: with SMTP id p5mr39163679otc.296.1577188581239; Tue, 24 Dec 2019 03:56:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577188581; cv=none; d=google.com; s=arc-20160816; b=necUXDwhC+R0IBC1HmybGxQPcnheUBQFb5KBXzvkV8Oi5eZjw9jzcvvb513MRKAJd4 C4Dvq24Z8vY3UGNpYbL0vXeFeS+Yfg8YUwZoaqal0d7kiN9kggVX7f/9cWq4aoFvHAlA Dih2qUS6NN+OJZrl+VDcNymzolMBlRHuD+l8gVrSvW8WfKhRpse+QwMSNhuBczMylrTZ Jt7auV1hbuxYoyLYS0Ru681cGdQEpOtX/YwmEfOmDr6zag225woY75ctBztNJlWR+p1Z cC3ybH8ii1Te0UcbhTv3mYSdQPNCEYH//FwyRVr+Mlto37bkWQhNWjT7GnYtl42eAAcK CpKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=fmq4urjTAkCVTPfY5NvWKmvwG5mkul1LGV9PhliCnXA=; b=vUKSLXgA4lYmhmpPjjZHokskBEbufAGINxl1BgmsH4VjEPXI8Paaoa37Vi3GQW1a6V /qjRvB8rOLHlRKp+DKYENNKHfnM6uiP9f2IXLzUhVQeTs/fvS+1CgDt1ezP1HXiV8V+b gNfZhCUtPdzrkWxFTaPwYNnO4MHFomenNN1w4KVDNruGo02h1lYzcTt/4R8igH7xKs0h Gt8FW5iZVt68kEMccIyT/qEaQpQ4mHKuP4+3CS/JQI5eCruwkUG2DracA01zAM9GYnaK MED9BZpGlOz3yoqXBIL0MexYpSbUcI4zaJVo+t1WIWYws2LcrS0eOR3A8nM6hQ+U5/28 XLQg== 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 f17si10345197otq.96.2019.12.24.03.56.10; Tue, 24 Dec 2019 03:56:21 -0800 (PST) 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 S1726244AbfLXLy1 (ORCPT + 99 others); Tue, 24 Dec 2019 06:54:27 -0500 Received: from foss.arm.com ([217.140.110.172]:51516 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbfLXLy1 (ORCPT ); Tue, 24 Dec 2019 06:54:27 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C16AF1FB; Tue, 24 Dec 2019 03:54:24 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1EA043F534; Tue, 24 Dec 2019 03:54:23 -0800 (PST) From: Qais Yousef To: Ingo Molnar , Peter Zijlstra Cc: Vincent Guittot , Dietmar Eggemann , Tejun Heo , surenb@google.com, Patrick Bellasi , Doug Smythies , Juri Lelli , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org, Qais Yousef Subject: [PATCH] sched/uclamp: Fix a bug in propagating uclamp value in new cgroups Date: Tue, 24 Dec 2019 11:54:04 +0000 Message-Id: <20191224115405.30622-1-qais.yousef@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a new cgroup is created, the effective uclamp value wasn't updated with a call to cpu_util_update_eff() that looks at the hierarchy and update to the most restrictive values. Fix it by ensuring to call cpu_util_update_eff() when a new cgroup becomes online. Without this change, the newly created cgroup uses the default root_task_group uclamp values, which is 1024 for both uclamp_{min, max}, which will cause the rq to to be clamped to max, hence cause the system to run at max frequency. The problem was observed on Ubuntu server and was reproduced on Debian and Buildroot rootfs. By default, Ubuntu and Debian create a cpu controller cgroup hierarchy and add all tasks to it - which creates enough noise to keep the rq uclamp value at max most of the time. Imitating this behavior makes the problem visible in Buildroot too which otherwise looks fine since it's a minimal userspace. Reported-by: Doug Smythies Tested-by: Doug Smythies Fixes: 0b60ba2dd342 ("sched/uclamp: Propagate parent clamps") Link: https://lore.kernel.org/lkml/000701d5b965$361b6c60$a2524520$@net/ Signed-off-by: Qais Yousef --- kernel/sched/core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 90e4b00ace89..bfe756dee129 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7100,6 +7100,12 @@ static int cpu_cgroup_css_online(struct cgroup_subsys_state *css) if (parent) sched_online_group(tg, parent); + +#ifdef CONFIG_UCLAMP_TASK_GROUP + /* Propagate the effective uclamp value for the new group */ + cpu_util_update_eff(css); +#endif + return 0; } -- 2.17.1