Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp573217imm; Thu, 6 Sep 2018 07:03:22 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYAgwVDsjXhzGLlxJ+MsRVGBIyI3kBCF/y4ixEGQZ810thfF7fj8kpj3H6ETqg6c9wm0wb8 X-Received: by 2002:a65:6413:: with SMTP id a19-v6mr2741376pgv.359.1536242602240; Thu, 06 Sep 2018 07:03:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536242602; cv=none; d=google.com; s=arc-20160816; b=Fff4VdeIfGXHo1BXtnG/6TT3JFneiQ9L+tmyCkiaXbSKmTmEi+t/cmP/7lXWreL+Ho Zt3fLUj62QlgpXC91f42hrLyl0vjq75WiThmm8GBBTY5GPOhATRyZMdC3UwBnUySlWdt C3mwb0njMUKW5tQlgqWE924CbhU2oKtghvHPO3p29SH3/sPr4wpgyLF4RliS2egChRRB 4DgzmvqPmbtYq0gp8krBLgAQkxwJbQwLuXGhL+E8BtRSKgI8jFidsFKbMqLWTUdK1FDP Rn+0CWqXB2LH84ErbGtfLmUXZRNeT0vE7BMlsMuvBqV2LV3sIUz/XR+qm6RZwPykxN97 njaQ== 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=CgSfJwHz+QEKRf31f9Kwidw93CvrSD4SWtIQJE8mKcI=; b=VGLRMBv5GmJfLTj9/iGh6TlcOQIIg24TDufV5kFbBz5eCgXSebVKYTh/zwL3HWZ9X3 6jCR6eOautuyuQHUpyZoWC9vEIE84Kx9v3+2ODz70fc25PMlEjKR7/WCf0fw5CIXYQmp +/Vr9goy8g1TG9GuXvE2RloL8YJVqDcCS5YruOQaewvuUF6aT1u2BaB5WpnC3GLxqZIu B5yLIcLhmmjTQ/g+v8jkiqdw41P4u8Xw+R5JnovblP2/TUcfgN03sqViJSkMl9e+QVNd hSC12s+4G4y0JkQ1UoBNvTU1nTa+hdz3rrjuSPpjHGNULWjXMoX4xpmVZzCndTBdLbJF isCA== 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 u26-v6si4687543pge.590.2018.09.06.07.03.02; Thu, 06 Sep 2018 07:03:22 -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 S1730051AbeIFSgN (ORCPT + 99 others); Thu, 6 Sep 2018 14:36:13 -0400 Received: from foss.arm.com ([217.140.101.70]:46292 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729534AbeIFSgN (ORCPT ); Thu, 6 Sep 2018 14:36:13 -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 E510180D; Thu, 6 Sep 2018 07:00:31 -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 228963F614; Thu, 6 Sep 2018 07:00:28 -0700 (PDT) Date: Thu, 6 Sep 2018 15:00:26 +0100 From: Patrick Bellasi To: Juri Lelli 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 , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , 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: <20180906140026.GC25636@e110439-lin> References: <20180828135324.21976-1-patrick.bellasi@arm.com> <20180828135324.21976-3-patrick.bellasi@arm.com> <20180906081728.GB27626@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180906081728.GB27626@localhost.localdomain> 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 06-Sep 10:17, Juri Lelli wrote: > On 28/08/18 14:53, Patrick Bellasi wrote: > > [...] > > > static inline int __setscheduler_uclamp(struct task_struct *p, > > const struct sched_attr *attr) > > { > > - if (attr->sched_util_min > attr->sched_util_max) > > - return -EINVAL; > > - if (attr->sched_util_max > SCHED_CAPACITY_SCALE) > > - return -EINVAL; > > + int group_id[UCLAMP_CNT] = { UCLAMP_NOT_VALID }; > > + int lower_bound, upper_bound; > > + struct uclamp_se *uc_se; > > + int result = 0; > > > > - p->uclamp[UCLAMP_MIN] = attr->sched_util_min; > > - p->uclamp[UCLAMP_MAX] = attr->sched_util_max; > > + mutex_lock(&uclamp_mutex); > > > > - return 0; > > + /* Find a valid group_id for each required clamp value */ > > + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) { > > + 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; > > + } > > + > > + result = uclamp_group_find(UCLAMP_MIN, attr->sched_util_min); > > + if (result == -ENOSPC) { > > + pr_err(UCLAMP_ENOSPC_FMT, "MIN"); > > + goto done; > > + } > > + group_id[UCLAMP_MIN] = result; > > + } > > + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) { > > + lower_bound = (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) > > + ? attr->sched_util_min > > + : p->uclamp[UCLAMP_MIN].value; > > + > > + if (lower_bound == UCLAMP_NOT_VALID) > > + lower_bound = 0; > > + if (attr->sched_util_max < lower_bound || > > + attr->sched_util_max > SCHED_CAPACITY_SCALE) { > > + result = -EINVAL; > > + goto done; > > + } > > + > > + result = uclamp_group_find(UCLAMP_MAX, attr->sched_util_max); > > + if (result == -ENOSPC) { > > + pr_err(UCLAMP_ENOSPC_FMT, "MAX"); > > + goto done; > > + } > > + group_id[UCLAMP_MAX] = result; > > + } > > Don't you have to reset result to 0 here (it seems what follows cannot > fail anymore)? Otherwise this function will return latest > uclamp_group_find return value, which will be interpreted as error if > not 0. Yes, wired.. it uses to work on my tests just because I return from the caller on !0 and: - that's just good enough to set by uclamps - my current rt-app integration does not check the sycall return value - my tests never request the clamp_group mapped on group_id=0 :( Will fix both this and the rt-app integration and the tests ! Cheers Patrick -- #include Patrick Bellasi