Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3758589imc; Thu, 14 Mar 2019 04:46:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqyL7hWJOM6ENUYRS92KS8En+QGnsVtRtNr4TbCU6MbhOrWbVy+vVcjdQWg8epiRz1GSuI1v X-Received: by 2002:a63:ea52:: with SMTP id l18mr45067377pgk.317.1552564015568; Thu, 14 Mar 2019 04:46:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552564015; cv=none; d=google.com; s=arc-20160816; b=h8GFoCWNrZlw2u47epwcsXW4EGx4UZDrBN3LITvkDyAOCv4TYrkZ26VY7apyjZgngl i8DwVEVZpS63LnQV/FwWk+k3SRlNxCgQpjmhU1mP87cyj4r4IV8QWZMKtrjW8cKTtg/N fGJVfkESf2+PgIgLEBpVA9D1TSRQ5Si6dLUMlqnBJ2jz5au95C5psiMhYjQJ4KLoo8Ud GBR6LDTRpwf/8uiUwxuZ5UULrSzVhKuxJaJd7EAgMMXuGfgehn/vGttiNhg+u1lIsi3J /uUSts8F0ckqWHoqXoVH63CkwD/mS2oXb+rRW/TbPtsm3QXRpkZVEbPamhVqTwqlYIAX fvjA== 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=Fyv/3yDUhFFkqeAob9G+4RcRJaGM/8Pb+a9j8datTGQ=; b=P9TCOAxDou8qqGBEVWayrO6VzzXhDBGdnFno9eaASLkhjgM+6NG0HDtUIEhmulZzzV 0l4lB9VgaCgKI7g3Zk59QQH43VIdx6w30TOW6L4NO2pBYxokmOr8QEpWMToLNQH8GkJh C9ecJpSK6swcx2rVh6sUCm+hpGJeY1LpT8PIY22WZW5i2AyMysTSr9EgizoKiOu3arE/ PGQW2m5vWvEwbasF552pNVP3oGdw+LyrxjATa51oZygvFd/eVZmyOLHpVuEvrQhSZgyj dLEhKwrrdG+iyJVYLFsGpYDUiDG04Is7yVEO+8uKnI8eIUj2Sc84fKpMmaAMTxKwUEg1 dRQw== 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 j19si12318947pgk.546.2019.03.14.04.46.40; Thu, 14 Mar 2019 04:46:55 -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 S1727436AbfCNLp5 (ORCPT + 99 others); Thu, 14 Mar 2019 07:45:57 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42986 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726825AbfCNLp5 (ORCPT ); Thu, 14 Mar 2019 07:45:57 -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 C1BFA80D; Thu, 14 Mar 2019 04:45:56 -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 CC7053F71D; Thu, 14 Mar 2019 04:45:53 -0700 (PDT) Date: Thu, 14 Mar 2019 11:45:51 +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 01/15] sched/core: uclamp: Add CPU's clamp buckets refcounting Message-ID: <20190314114551.6kfozh6rpw5mornb@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-2-patrick.bellasi@arm.com> <20190313140925.GE5922@hirez.programming.kicks-ass.net> <20190313152359.lkyzel7fakjoi5hu@e110439-lin> <20190313194619.GR2482@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313194619.GR2482@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 20:46, Peter Zijlstra wrote: > On Wed, Mar 13, 2019 at 03:23:59PM +0000, Patrick Bellasi wrote: > > On 13-Mar 15:09, Peter Zijlstra wrote: > > > On Fri, Feb 08, 2019 at 10:05:40AM +0000, Patrick Bellasi wrote: > > > > > +static inline void uclamp_rq_update(struct rq *rq, unsigned int clamp_id) > > > > +{ > > > > + struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket; > > > > + unsigned int max_value = uclamp_none(clamp_id); > > > > > > That's 1024 for uclamp_max > > > > > > > + unsigned int bucket_id; > > > > + > > > > + /* > > > > + * Both min and max clamps are MAX aggregated, thus the topmost > > > > + * bucket with some tasks defines the rq's clamp value. > > > > + */ > > > > + bucket_id = UCLAMP_BUCKETS; > > > > + do { > > > > + --bucket_id; > > > > + if (!rq->uclamp[clamp_id].bucket[bucket_id].tasks) > > > > + continue; > > > > + max_value = bucket[bucket_id].value; > > > > > > but this will then _lower_ it. That's not a MAX aggregate. > > > > For uclamp_max we want max_value=1024 when there are no active tasks, > > which means: no max clamp enforced on CFS/RT "idle" cpus. > > > > If instead there are active RT/CFS tasks then we want the clamp value > > of the max group, which means: MAX aggregate active clamps. > > > > That's what the code above does and the comment says. > > That's (obviously) not how I read it.... maybe something like: > > static inline void uclamp_rq_update(struct rq *rq, unsigned int clamp_id) > { > struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket; > int i; > > /* > * Since both min and max clamps are max aggregated, find the > * top most bucket with tasks in. > */ > for (i = UCLMAP_BUCKETS-1; i>=0; i--) { > if (!bucket[i].tasks) > continue; > return bucket[i].value; > } > > /* No tasks -- default clamp value */ > return uclamp_none(clamp_id); > } > > would make it clearer? Fine for me, I'll then change the name in something else since that's not more an "_update" by moving the WRITE_ONCE into the caller. -- #include Patrick Bellasi