Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp808456imm; Fri, 14 Sep 2018 06:42:18 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZdbY4MboKq5kidPIwXi8XX+M3nSi7zzvre/6y4TKVWHUJ8On9OYd/91v3LARJNVzqpFwii X-Received: by 2002:a17:902:6ac5:: with SMTP id i5-v6mr12404441plt.232.1536932538760; Fri, 14 Sep 2018 06:42:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536932538; cv=none; d=google.com; s=arc-20160816; b=I0NQLY3sutMdhTK+62FDYAqrrpLM9ke8NphntQryK/pa4YlKfr3P04Y5cr7tUN2C99 jnDfN9AxpDR5EVRucxZLbGtBIUAstzYI0Qy9GioZ7vviR28La0mQ+m1c9UVNLEqhPRed r+N+jRfzVlJBF+oBybvvWvN/wjCQwZ0LmU3EvYRhl+FXtsTEZ4QyME5U4L5/LrgfMkid HYijcU0hD+vi27I2gwgHYeauLmC1scCFxrfoKzeqhoFb2CSf2LOjcq2uN+P8Q7CsXeIR hBMGkAB8HDsmbMivEvQCeAXqQimNtZT7rCYw5qi0LnIdtv7wQZgQgVGYCOzjCEXeYCqr xqUg== 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=Z3r7Gp+dbMuvqs/wJAMhPid50NMniJed2PjkScG4dBw=; b=ffTw6n3uden7NLieTJAXazI9HxoIOVKFHeTITYYzaFxq1Hd9kSijXL6fHpOKGLfYwU TVXSj/grsVi4pgFLSaZAF3GDfzkoiSyfpwBh9zIUuFrxze5heliQFPXanhZuLyQqw94H IRLISEHt3zn+iizXW1sRyzRtWEbN5mDRhO/e9Y5E9cF7qNgfL3QR7GtalUVjKiVdFc1O VceJufJjNSgcT5bl54DNKJx1/QEyCYnIqLjAn9f7YCfiaCp4m2utH2gz6LnC57sIGa/d 2LbmcFegTshr2eug54BNGOzNqY7JNp0RAx+qq1bDV1WyQPD0B9O0f5eyX9n2WX68kULv zdgw== 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 v8-v6si7203663pga.487.2018.09.14.06.42.02; Fri, 14 Sep 2018 06:42:18 -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 S1728090AbeINS4I (ORCPT + 99 others); Fri, 14 Sep 2018 14:56:08 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33668 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727672AbeINS4I (ORCPT ); Fri, 14 Sep 2018 14:56:08 -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 454DA18A; Fri, 14 Sep 2018 06:41:34 -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 75A6A3F703; Fri, 14 Sep 2018 06:41:31 -0700 (PDT) Date: Fri, 14 Sep 2018 14:41:28 +0100 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v4 03/16] sched/core: uclamp: add CPU's clamp groups accounting Message-ID: <20180914134128.GP1413@e110439-lin> References: <20180828135324.21976-1-patrick.bellasi@arm.com> <20180828135324.21976-4-patrick.bellasi@arm.com> <20180913191209.GY24082@hirez.programming.kicks-ass.net> <20180914090751.GN1413@e110439-lin> <20180914115217.GI24124@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180914115217.GI24124@hirez.programming.kicks-ass.net> 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 14-Sep 13:52, Peter Zijlstra wrote: > On Fri, Sep 14, 2018 at 10:07:51AM +0100, Patrick Bellasi wrote: > > On 13-Sep 21:12, Peter Zijlstra wrote: > > > On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote: > > > > +static inline void uclamp_cpu_get_id(struct task_struct *p, > > > > + struct rq *rq, int clamp_id) > > > > +{ > > > > + struct uclamp_group *uc_grp; > > > > + struct uclamp_cpu *uc_cpu; > > > > + int clamp_value; > > > > + int group_id; > > > > + > > > > + /* Every task must reference a clamp group */ > > > > + group_id = p->uclamp[clamp_id].group_id; > > > > > > > +} > > > > + > > > > +static inline void uclamp_cpu_put_id(struct task_struct *p, > > > > + struct rq *rq, int clamp_id) > > > > +{ > > > > + struct uclamp_group *uc_grp; > > > > + struct uclamp_cpu *uc_cpu; > > > > + unsigned int clamp_value; > > > > + int group_id; > > > > + > > > > + /* New tasks don't have a previous clamp group */ > > > > + group_id = p->uclamp[clamp_id].group_id; > > > > + if (group_id == UCLAMP_NOT_VALID) > > > > + return; > > > > > > *confused*, so on enqueue they must have a group_id, but then on dequeue > > > they might no longer have? > > > > Why not ? > > That's what it says on the tin, right? enqueue: "every task must reference clamp > group" while on dequeue: "new tasks don't have a (previous) clamp group" > and we check for NOT_VALID. Oh, right... I've got confused me too since I was looking @enqueue. You right, @dequeue we always a group_id. The check @dequeue time was required only before v3 because of the way defaults (i.e. no clamps) was tracked. Will remove it in v5, thanks! BTW, my previous explanation was also incorrect, since the logic for init_task initialization is: uc_se->group_id = UCLAMP_NOT_VALID; uclamp_group_get(value) where the first assignment is required just to inform uclamp_group_get() that we don't need to uclamp_group_put() a previous (non existing at init time) clamp group. Thus, at the end of the two instructions above we end up with an init_task which has a !UCLAMP_NOT_VALID group id, which is then cloned by forked tasks. Cheers, Patrick -- #include Patrick Bellasi