Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3082475imc; Wed, 13 Mar 2019 08:25:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqx49HLYhW8SDjR9/P5y+jqxsskp/K+G6A2LDSWPZZC8no1B449B/AwsVXlGla/hnAZ3wAL1 X-Received: by 2002:a17:902:3283:: with SMTP id z3mr46593929plb.155.1552490720925; Wed, 13 Mar 2019 08:25:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552490720; cv=none; d=google.com; s=arc-20160816; b=FISS1DZk2ARsGESbOE+BKKxkxS6hgnYQsxtpp/ZGCL5kkoRGF++kKnRbdEu14UytHz 6jGc1fPawF6tUqMJ+xA8pUz6lL1HYwpvIIfL/yrQF6eFECHVYtoXsUO2SKP0SV26RUoL QfNHhbVmUI75Ighv2935sRJSW2GvLLIWXBWW/gJ+sml3hCoapKd7GfX8I9l31ceCfIbs 0yu9ZhbzdZojZuXo+U39S8VWUKHniBclg9iXP4XpixzCaTVEcR10/tk9MaiTIYMph6sN 352VJ6dAOn8NzffipPCvvsXxUSCCfiDapHJ6irVa49Q8tS3yASvaJUFuqzoFnM33orB3 iXYg== 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=iMMwgmRPZWSeva+Z6qTNLcSZvYs/ZzmbA4mcNGRVyPY=; b=jUV0I6qR/F89LYSrXLdgjTRLVBslF8NH4ZVG9VqiBJObrRuKS7aqPewDPcHcpBNDtb lAfw9ebsX0ClDs60TovLAz87l9RAcOI0r3vcoIdEJulomglnOjQu3caYm1ZFzIgpC9f5 4We0JSDog/5kn+e6OTNGv3E9fh+jZ7RBD7wU5dmdLxBiB65a1DjaeLFEu6zyzqVQhi0d yqTv5ltkd7nO9thZlBFKquno2sl6Jbqsk0XWKr8IM14o9GUSjC/d9BvM0iS3JtQfE6iM 4feLlHwBliCIFY8es0sTdnVvwLgCSXew1i48o5pt3alowM9l9147rJ9tzGbiL+NIdyly FP4g== 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 u5si10386475pgi.162.2019.03.13.08.25.03; Wed, 13 Mar 2019 08:25:20 -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 S1726735AbfCMPYG (ORCPT + 99 others); Wed, 13 Mar 2019 11:24:06 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59128 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbfCMPYF (ORCPT ); Wed, 13 Mar 2019 11:24:05 -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 3403D80D; Wed, 13 Mar 2019 08:24:05 -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 3F8753F71D; Wed, 13 Mar 2019 08:24:02 -0700 (PDT) Date: Wed, 13 Mar 2019 15:23:59 +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: <20190313152359.lkyzel7fakjoi5hu@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-2-patrick.bellasi@arm.com> <20190313140925.GE5922@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313140925.GE5922@hirez.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 15:09, Peter Zijlstra wrote: > On Fri, Feb 08, 2019 at 10:05:40AM +0000, Patrick Bellasi wrote: > > +static inline unsigned int uclamp_none(int clamp_id) > > +{ > > + if (clamp_id == UCLAMP_MIN) > > + return 0; > > + return SCHED_CAPACITY_SCALE; > > +} > > + > > +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. > > + break; > > + } while (bucket_id); > > + > > + WRITE_ONCE(rq->uclamp[clamp_id].value, max_value); > > +} -- #include Patrick Bellasi