Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3825288imm; Mon, 20 Aug 2018 05:29:17 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyqVOZIBPqdfF3LSIQUiyyjB50F13asJGAkPTWoOIaY3yGVMD1DUYMUNlrOVtnVi9CA1TUO X-Received: by 2002:a17:902:5ac2:: with SMTP id g2-v6mr15320959plm.90.1534768157032; Mon, 20 Aug 2018 05:29:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534768157; cv=none; d=google.com; s=arc-20160816; b=enQiv3NTR7QDI3QPFv7pvlweXVubuYeCuyyIJ+mlhXNG7zOImhCx6kThZ9e3e9iQio mBT0pRaqJo/WWAuldmDKStP/Vp45DbcFgfUvEdV4cwHEv4okziXTRkIkfgcGXCG+eJKi tai85cj/ZFRzTsBMCbPsAke8ZAqgL5wJzrLLjg21JGH70xqOuez9HmXQ2wsDrbvft94/ rneTGEH2MutxQacYQ+klufXCjetPUqix8ZnwW0XhkQ/ULhDe1NCuzt9Db/OfFnp4sDlr jrGUlTOZc/x9jp4mz0p1qK2WVVf3a97nQP4RK8Lpr97upW4cjo9FDRHB+AX6JnsIMR8f OR+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=lg1NK2AO0prBbfgs5+tKl4zpyF4DxRSjSi/GILzGkVI=; b=eP8fevhC6Aw1j02iLrOWNPsaeQBlI28RhKqYO4JhlnkPUZ2kNbj8rcdtmmYpZvF87m t/W/BtAhwBh71nJf8L+rjbr4z7W27WSudH3lCtZPUBdfVRhBdhIPf6iFtqdKJI5/LI+z H3uXecv5h3aOr0P+pEPI45DAybGLtPNVJm9eoExA5ZrMXOUfULiDujpqklMkThVF//PJ jxpURO4IpZCa0bQO1vSNDh8oh6wb6NHlqCy/wEDL78SNmp92YX/722q6NrvPpkcHqE4G bKVVCh+UAnbiAfWlFQA1Ta5XD+gEq9ZIoBat6wmiQUMFgYAo/m2jZeeskE9Q2i/bfKSr J74g== 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 31-v6si9740976plj.48.2018.08.20.05.29.01; Mon, 20 Aug 2018 05:29:16 -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 S1726785AbeHTPnA (ORCPT + 99 others); Mon, 20 Aug 2018 11:43:00 -0400 Received: from foss.arm.com ([217.140.101.70]:36938 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726535AbeHTPnA (ORCPT ); Mon, 20 Aug 2018 11:43:00 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1D46DED1; Mon, 20 Aug 2018 05:27:34 -0700 (PDT) Received: from e110439-lin (e110439-lin.Emea.Arm.com [10.4.12.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7266D3F2EA; Mon, 20 Aug 2018 05:27:31 -0700 (PDT) Date: Mon, 20 Aug 2018 13:27:28 +0100 From: Patrick Bellasi To: Dietmar Eggemann Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v3 12/14] sched/core: uclamp: add system default clamps Message-ID: <20180820122728.GM2960@e110439-lin> References: <20180806163946.28380-1-patrick.bellasi@arm.com> <20180806163946.28380-13-patrick.bellasi@arm.com> <2816b340-ca91-4d09-1610-df05a9893da2@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2816b340-ca91-4d09-1610-df05a9893da2@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20-Aug 12:18, Dietmar Eggemann wrote: > On 08/06/2018 06:39 PM, Patrick Bellasi wrote: > >Clamp values cannot be tuned at the root cgroup level. Moreover, because > >of the delegation model requirements and how the parent clamps > >propagation works, if we want to enable subgroups to set a non null > >util.min, we need to be able to configure the root group util.min to the > >allow the maximum utilization (SCHED_CAPACITY_SCALE = 1024). > > Why 1024 (100)? Would any non 0 value work here? Something less then 100% will clamp subgroups util.min to that value. If we want to allow the full span to subgroups, the root group should not enforce boundaries... hence util.min should be set to 100%. > [...] > > >@@ -1269,6 +1296,75 @@ static inline void uclamp_group_get(struct task_struct *p, > > uclamp_group_put(clamp_id, prev_group_id); > > } > >+int sched_uclamp_handler(struct ctl_table *table, int write, > >+ void __user *buffer, size_t *lenp, > >+ loff_t *ppos) > >+{ > >+ int group_id[UCLAMP_CNT] = { UCLAMP_NOT_VALID }; > >+ struct uclamp_se *uc_se; > >+ int old_min, old_max; > >+ int result; > >+ > >+ mutex_lock(&uclamp_mutex); > >+ > >+ old_min = sysctl_sched_uclamp_util_min; > >+ old_max = sysctl_sched_uclamp_util_max; > >+ > >+ result = proc_dointvec(table, write, buffer, lenp, ppos); > >+ if (result) > >+ goto undo; > >+ if (!write) > >+ goto done; > >+ > >+ if (sysctl_sched_uclamp_util_min > sysctl_sched_uclamp_util_max) > >+ goto undo; > >+ if (sysctl_sched_uclamp_util_max > 1024) > >+ goto undo; > >+ > >+ /* Find a valid group_id for each required clamp value */ > >+ if (old_min != sysctl_sched_uclamp_util_min) { > >+ result = uclamp_group_find(UCLAMP_MIN, sysctl_sched_uclamp_util_min); > >+ if (result == -ENOSPC) { > >+ pr_err("Cannot allocate more than %d UTIL_MIN clamp groups\n", > >+ CONFIG_UCLAMP_GROUPS_COUNT); > >+ goto undo; > >+ } > >+ group_id[UCLAMP_MIN] = result; > >+ } > >+ if (old_max != sysctl_sched_uclamp_util_max) { > >+ result = uclamp_group_find(UCLAMP_MAX, sysctl_sched_uclamp_util_max); > >+ if (result == -ENOSPC) { > >+ pr_err("Cannot allocate more than %d UTIL_MAX clamp groups\n", > >+ CONFIG_UCLAMP_GROUPS_COUNT); > >+ goto undo; > >+ } > >+ group_id[UCLAMP_MAX] = result; > >+ } > >+ > >+ /* Update each required clamp group */ > >+ if (old_min != sysctl_sched_uclamp_util_min) { > >+ uc_se = &uclamp_default[UCLAMP_MIN]; > >+ uclamp_group_get(NULL, UCLAMP_MIN, group_id[UCLAMP_MIN], > >+ uc_se, sysctl_sched_uclamp_util_min); > >+ } > >+ if (old_max != sysctl_sched_uclamp_util_max) { > >+ uc_se = &uclamp_default[UCLAMP_MAX]; > >+ uclamp_group_get(NULL, UCLAMP_MAX, group_id[UCLAMP_MAX], > >+ uc_se, sysctl_sched_uclamp_util_max); > >+ } > >+ > >+ if (result) { > >+undo: > >+ sysctl_sched_uclamp_util_min = old_min; > >+ sysctl_sched_uclamp_util_max = old_max; > >+ } > > This looks strange! In case uclamp_group_find() returns free_group_id > instead of -ENOSPC, the sysctl min/max values are reset? > > I was under the assumption that I could specify: > > sysctl_sched_uclamp_util_min = 40 (for boosting) > sysctl_sched_uclamp_util_max = 80 (for clamping) > > with an empty cpu controller hierarchy and then those values become the > .effective values of (a first level) task group? You right, I forgot to reset result=0 once we passed the two uclamp_group_find() calls. Will fix in v4. Cheers Patrick -- #include Patrick Bellasi