Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp456817ima; Fri, 15 Mar 2019 06:42:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqwdviJNOWC20DOERRQl6Hqc85ajaH9BaL3DusScqS0fHwI6Mmx3ff/tFVf4kmlSrVuwbAFj X-Received: by 2002:a62:1b92:: with SMTP id b140mr4186332pfb.159.1552657367868; Fri, 15 Mar 2019 06:42:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552657367; cv=none; d=google.com; s=arc-20160816; b=V+HeMNyctVT+KceWGjoiiAN9d6fiFsT5kdIhyD65hHRRoRNeHeL7Ja73+Z5lexBj/i tzWPgjoo72DnVPM9z97CPoyqgqf0rVPwS+xiudX6hgNHODo9fby9pzcxtTcD79icHJ72 KV4o1f+hz7u5JxhODVAmHBZ1REpSMNmo3nDHyCveIs+eaqaYuzl4cHLS7V2Xyb8aAF0z vAalAlLrzWuqPv1AC7QP/460WHryDfLoav2bSNXWu9cJtfj6Vk9EglKEbudCOcbOyUi4 TYjVkowRkGZgzxyg2s1Y7IBRYpZBuu3iMlbSG6CU3ieVYPLRrIMqFqiePfVfj7Wxx4IX aaFQ== 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=rQ4C8d5+YLuhD+03jKRhwAlke1L3gaWw1Du4xZUNYp0=; b=W2qU7IVb3W3CZvft5vmswOoBM1gQEe7MUwmmO9XmfujGwfobeCPfi2kWb3Oxy8md3D HaREmIlHAYxECcVe33WkDnC4yXmSuLviXDfxkUpWBqKz5T5+rPipl+jpQqMuZBeo2FFS yG//qObYzfN9qInIN74IgqrnF/nHBMGgoDL7eQlMlOhReFloTEWMwg62BYZrYgKwfH2B eVq9KAL/xKaR91mTLDtrPI7XVid0fVSptWGlhSzRj7TTu78XdwnnysaG9RYjAsd/QtkS Sf/0BkVpuVeEviigJ+fmyLUv1BvgD+i1C7Ch9lvQGq4dBbP/bERbDeLiwbXL8dkTkk40 uWBw== 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 w7si1780775pgs.155.2019.03.15.06.42.32; Fri, 15 Mar 2019 06:42:47 -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 S1729092AbfCONlt (ORCPT + 99 others); Fri, 15 Mar 2019 09:41:49 -0400 Received: from foss.arm.com ([217.140.101.70]:59684 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727705AbfCONlt (ORCPT ); Fri, 15 Mar 2019 09:41:49 -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 B51B5A78; Fri, 15 Mar 2019 06:41:48 -0700 (PDT) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0C723F614; Fri, 15 Mar 2019 06:41:45 -0700 (PDT) Date: Fri, 15 Mar 2019 13:41:39 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v7 03/15] sched/core: uclamp: Add system default clamps Message-ID: <20190315134139.hrw22zaut3shfs4d@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-4-patrick.bellasi@arm.com> <20190313143240.GH5922@hirez.programming.kicks-ass.net> <20190313170940.ngiafkmiijryhl2k@e110439-lin> <20190313201010.GU2482@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313201010.GU2482@worktop.programming.kicks-ass.net> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13-Mar 21:10, Peter Zijlstra wrote: > On Wed, Mar 13, 2019 at 05:09:40PM +0000, Patrick Bellasi wrote: > > > Yes, that should be possible... will look into splitting this out in > > v8 to have something like: > > > > ---8<--- > > struct uclamp_req { > > /* Clamp value "requested" by a scheduling entity */ > > unsigned int value : bits_per(SCHED_CAPACITY_SCALE); > > unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > unsigned int active : 1; > > unsigned int user_defined : 1; > > } > > > > struct uclamp_eff { > > unsigned int value : bits_per(SCHED_CAPACITY_SCALE); > > unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > } > > No, have _1_ type. There is no point what so ever to splitting this. > > Also, what's @user_defined about, I don't think I've seen that in the > parent patch. That's a flag added by one of the following patches, but with the change you are suggesting below... > > struct task_struct { > > // ... > > #ifdef CONFIG_UCLAMP_TASK > > struct uclamp_req uclamp_req[UCLAMP_CNT]; > > struct uclamp_eff uclamp_eff[UCLAMP_CNT]; > > struct uclamp_se uclamp[UCLAMP_CNT]; > struct uclamp_se uclamp_req[UCLAMP_CNT]; > > Where the first is the very same introduced in patch #1, and leaving it > in place avoids having to update the sites already using that (or start > #1 with the _eff name to avoid having to change things around?). > > > #endif > > // ... > > } > > > > static inline struct uclamp_eff > > uclamp_eff_get(struct task_struct *p, unsigned int clamp_id) > > { > > struct uclamp_eff uc_eff = p->uclamp_eff[clamp_id]; > > just this ^, these lines seem like a superfluous duplication: > > > uc_eff.bucket_id = p->uclamp_req[clamp_id].bucket_id; > > uc_eff.value = p->uclamp_req[clamp_id].value; > > > > if (unlikely(uc_eff.clamp_value > uclamp_default[clamp_id].value)) { > > uc_eff.clamp_value = uclamp_default[clamp_id].value; > > uc_eff.bucket_id = uclamp_default[clamp_id].bucket_id; > > and: > > uc = uclamp_default[clamp_id]; ... with things like the above line it becomes quite tricky to exploit the uclamp_se bitfield to track additional flags. I'll try to remove the need for the "user_defined" flag, as long as we have only the "active" you we can still manage to keep it in uclamp_se. If instead we really need more flags, we will likely have to move them into a separate bitfield. :/ > > > } > > > > return uc_eff; > > } > > > > static inline void > > uclamp_eff_set(struct task_struct *p, unsigned int clamp_id) > > { > > p->uclamp_eff[clamp_id] = uclamp_eff_get(p, clamp_id); > > } > > ---8<--- > > > > Is that what you mean ? > > Getting there :-) Yeah... let see :) -- #include Patrick Bellasi