Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp4008494imc; Thu, 14 Mar 2019 10:07:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyr2vNrJhlbv/J6pcKqQfh5DhVszR5bJIMTY5hbIWZqBg9MXcpd6fob2WEst/xuTPiVydAN X-Received: by 2002:a65:6483:: with SMTP id e3mr6763922pgv.273.1552583253945; Thu, 14 Mar 2019 10:07:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552583253; cv=none; d=google.com; s=arc-20160816; b=c2oOAuIfOKNZFKM7IB15QXHefgXlCW/U4+rCxoLrDjnm/gl8+02LId5mrEA30EWEXN 2GtXP5e+atiAB2YC+1Xj2TKwMPROqJg62VXLWavdgWeCtDYHVxFIEEGxJFZBv+NOXnRM MQe8crXj5NWpaSZjk0kZ74xYFYHzQjPVH/PjBsAxcjWOYQdlzGX+K4IvZOCfoJRDY1j/ lxXVMhPoBUn3vftrG2EHWso5vt/YnEHToZYNDoVjMr8O0tV0gHJAZU2Xx/V1z8LuGdKB KOeuRCc9ixLZOsm1SMVVYMfSZgfa+KPPZ0QwTK6/GPCuQY3wKK5LDBn4fp488IC9rnaC /fhA== 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=/13hVQC1dVBXj2M8x0ewWH+L4akJZk6gh4pnmxGu93U=; b=a+qGgSp0m3FqMkPpo9CPOFDNskxERKC36AYksJcqhbD6Bna/bVp7fSA9UuyNBUxCa0 11ngOJKpnoLVSelHh1ZEokVCU5OU7yg4RT+951pV+JR8zfAjBtPHJRzSh3zhmPJF5rGD csqQAzFNib0hw8L+RiANGrAkBH2aPbziPAurGFPI3dwAHBi4yny84cgIAVX5sIIq63No qMG2nkhQDadLkU5DoFZcdtu5uRBl4ZSbEMPw5ISvNoQgIW2DHC8YKMh0ZjWqp6oRcy9G zoJTO+xzgOZQvBdBJqZ3hLjekcc8n3fyWkypmwKpz2l59AXv0ozYBl+l8+d2tLCASIrS 1YBw== 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 y14si13570513pll.378.2019.03.14.10.07.18; Thu, 14 Mar 2019 10:07:33 -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 S1727274AbfCNRG0 (ORCPT + 99 others); Thu, 14 Mar 2019 13:06:26 -0400 Received: from foss.arm.com ([217.140.101.70]:47720 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbfCNRG0 (ORCPT ); Thu, 14 Mar 2019 13:06:26 -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 587C180D; Thu, 14 Mar 2019 10:06:25 -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 642B53F71D; Thu, 14 Mar 2019 10:06:22 -0700 (PDT) Date: Thu, 14 Mar 2019 17:06:19 +0000 From: Patrick Bellasi To: Suren Baghdasaryan Cc: Peter Zijlstra , LKML , 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 Subject: Re: [PATCH v7 02/15] sched/core: uclamp: Enforce last task UCLAMP_MAX Message-ID: <20190314170619.rt6yhelj3y6dzypu@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-3-patrick.bellasi@arm.com> <20190313141253.GG5922@hirez.programming.kicks-ass.net> <20190313161646.fp2gswuqgzi7z7ow@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 17:29, Suren Baghdasaryan wrote: > On Wed, Mar 13, 2019 at 9:16 AM Patrick Bellasi wrote: > > > > On 13-Mar 15:12, Peter Zijlstra wrote: > > > On Fri, Feb 08, 2019 at 10:05:41AM +0000, Patrick Bellasi wrote: > > > > +static inline void uclamp_idle_reset(struct rq *rq, unsigned int clamp_id, > > > > + unsigned int clamp_value) > > > > +{ > > > > + /* Reset max-clamp retention only on idle exit */ > > > > + if (!(rq->uclamp_flags & UCLAMP_FLAG_IDLE)) > > > > + return; > > > > + > > > > + WRITE_ONCE(rq->uclamp[clamp_id].value, clamp_value); > > > > + > > > > + /* > > > > + * This function is called for both UCLAMP_MIN (before) and UCLAMP_MAX > > > > + * (after). The idle flag is reset only the second time, when we know > > > > + * that UCLAMP_MIN has been already updated. > > > > > > Why do we care? That is, what is this comment trying to tell us. > > > > Right, the code is clear enough, I'll remove this comment. > > It would be probably even clearer if rq->uclamp_flags &= > ~UCLAMP_FLAG_IDLE is done from inside uclamp_rq_inc after > uclamp_rq_inc_id for both clamps is called. Good point! I'll move it there to have something like: ---8<--- static inline void uclamp_rq_inc(struct rq *rq, struct task_struct *p) { unsigned int clamp_id; if (unlikely(!p->sched_class->uclamp_enabled)) return; for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) uclamp_rq_inc_id(p, rq, clamp_id); /* Reset clamp holding when we have at least one RUNNABLE task */ if (rq->uclamp_flags & UCLAMP_FLAG_IDLE) rq->uclamp_flags &= ~UCLAMP_FLAG_IDLE; } ---8<--- -- #include Patrick Bellasi