Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5764518imm; Wed, 12 Sep 2018 10:43:03 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ18fwIrxceTk19cnD66CbN8MUBmGLP5bry7ChHIKer4KNLEyQL50lXuUp8x2M3dnG08R+E X-Received: by 2002:a63:a5c:: with SMTP id z28-v6mr3398544pgk.209.1536774183097; Wed, 12 Sep 2018 10:43:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536774183; cv=none; d=google.com; s=arc-20160816; b=ToUeugmYLw/CmL+XSmt9QL3fWEw58cbxEhdBNDNouj2xm5vf0ArQjgQSqHrwu1Mdcz OycTSUVRACEUUeerI8maX6VBGJOaGaG1V+V6ejdin2euofCyFaynuIGmcKR++iW2+9PG lFPuhwNTukNa0NeKAy8P0nMnWlt3Y6fzM1Mj8VLZ1Tjc16/YBcZH20ZSR1YRIWJHlByt XmFhEyA6+aJZr0mGAWB6WG8QFpX4b5PX4+xVaJJgllOlkApIpYbmIWVfj7I/a/kjEQFw 9evE49u0CscQwFTy+tE4OUeFg7cnjEZzm5EEqpivG8TbTNuxGBt8lmxCQoxK4JMpjRMG Ggmg== 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; bh=0zIR1wSHqCTNNTru0lLA//xhtMv26R/6rFbEhq4OX8k=; b=BqXJXMHZWTFkf2B8R6qMY23mEW/8JZNu/Q3mE+BfQYR21gn7GoGNz3QurxcelAGNqj GvlEdUZXLOumtiKUJJ3gWZCrQT+Z+SIx9ART7QLPJXHgqEWo7+CTxqTk2Ar2xpdqVzVL RK3a11iDbQVv2Fh7AQP4zrfe8dxNG6yC1rOGj2cKwtMl4uZVyDg18tH8UYRHPpGQcaaC q3leJ//vkzLXyO6om3SsqaJD2f3+/qIdiWW7ijqI++D+bfDWpPyZQRpmojUrS/3g+byN 1SDGo9bVMkd+p492PuoWK/oKljZRmiTi0z+JssnOnywnsl46xvItc7UHNBNJltwWPHr9 y3/Q== 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 v20-v6si1718647pgk.682.2018.09.12.10.42.48; Wed, 12 Sep 2018 10:43:03 -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 S1728004AbeILWrt (ORCPT + 99 others); Wed, 12 Sep 2018 18:47:49 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:36640 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727161AbeILWrs (ORCPT ); Wed, 12 Sep 2018 18:47:48 -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 ABD937A9; Wed, 12 Sep 2018 10:42:14 -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 DD15F3F557; Wed, 12 Sep 2018 10:42:11 -0700 (PDT) Date: Wed, 12 Sep 2018 18:42:09 +0100 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v4 02/16] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups Message-ID: <20180912174209.GI1413@e110439-lin> References: <20180828135324.21976-1-patrick.bellasi@arm.com> <20180828135324.21976-3-patrick.bellasi@arm.com> <20180912162427.GA24106@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180912162427.GA24106@hirez.programming.kicks-ass.net> 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 12-Sep 18:24, Peter Zijlstra wrote: > On Tue, Aug 28, 2018 at 02:53:10PM +0100, Patrick Bellasi wrote: > > static inline int __setscheduler_uclamp(struct task_struct *p, > > const struct sched_attr *attr) > > But large for inline now. Yes, Suren also already pointed that out... already gone in my v5 ;) > > { > > + int group_id[UCLAMP_CNT] = { UCLAMP_NOT_VALID }; > > + int lower_bound, upper_bound; > > + struct uclamp_se *uc_se; > > + int result = 0; > > I think the thing would become much more readable if you set > lower/upper_bound right here. Do you mean the bits I've ---8<---ed below ? > > > > + mutex_lock(&uclamp_mutex); > > > > + /* Find a valid group_id for each required clamp value */ > > + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) { ---8<--- > > + upper_bound = (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) > > + ? attr->sched_util_max > > + : p->uclamp[UCLAMP_MAX].value; > > + > > + if (upper_bound == UCLAMP_NOT_VALID) > > + upper_bound = SCHED_CAPACITY_SCALE; > > + if (attr->sched_util_min > upper_bound) { > > + result = -EINVAL; > > + goto done; > > + } ---8<--- Actually it could also make sense to have them before the mutex ;) > > + > > + result = uclamp_group_find(UCLAMP_MIN, attr->sched_util_min); > > + if (result == -ENOSPC) { > > + pr_err(UCLAMP_ENOSPC_FMT, "MIN"); > > AFAICT this is an unpriv part of the syscall; and you can spam the log > without limits. Not good. Good point, will better check this. [...] Cheers, Patrick -- #include Patrick Bellasi