Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3912209imc; Thu, 14 Mar 2019 08:03:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqxatRcHLRVE1Y7EeZ24Jz2wuhw9nnL7ZkL2H4jURWNEbpJtDHVpJ1ZoG+slU0TGqOl4JPrO X-Received: by 2002:a62:5543:: with SMTP id j64mr49767238pfb.105.1552575799194; Thu, 14 Mar 2019 08:03:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552575799; cv=none; d=google.com; s=arc-20160816; b=j/4Hvci8zZmV+F7KeJ3A6x6pYU07T3X4NmeYYb2SA3Q+FXeXC58qEvcwpN4sC7qCsM ZHLXdhObOQNpiYqXJDeFRPvRyKoOINPkYq9XR2kQHb6/1XCtHBi/vKfHj42j42n6n3vC AgHIaw5tSmwi1BORjHT/3n10HT9k8f4e9qzlegDkPY8GTbTq9gueGVJPenKUcpM4wvJl xJejCzVeynh+uDmQ1WrE09vgqUZSwcFWgKA6k0FNnYtucDDYnLU6pyqNxJ05+Pgk7iv4 kRl/fAkmI4HBIa7u0FpxLMT+Dv1lPdT4mWcdfvt/ba3BGsHRqnkiIGbWdUQEHCobKAFF bM0g== 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=sl5EXefkn11fEIZ79oa9oJZr4RN4SXYJyDTbn3QqdD0=; b=F6r7ow7Toh2ikfo2Rnz8qbg462+9Jbtk6U96R3H0bAlX4NbZbRbusZbtPA7BlX0xDh 6AFpTTLfXJ5zII6joQRciIV3IuAiYgDUiBXHHR3pifeq2dcPKvl8WbOQSU4U5AjhpzBz DjMe/qfVkcGh4mVT6rnxxb9kOly5iUkBRoo5cgSOp8ZHIXcOi9fuJkQ0J0XcHPZfo9xu Q52OpXa2pRECbCakRsmXgdd9i+Hzlt7QRM00Z9sDcUt3Gf89OO2LVYssW+scLq2S7le6 Qs+BdjuLhrHIvz3fCKKC24rZ79V7weiAShH5lFIPBa2HX+vq+Py9SzW7IhVVtFXQJxMR 1hZQ== 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 h3si12851900pgn.68.2019.03.14.08.03.02; Thu, 14 Mar 2019 08:03:19 -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 S1726889AbfCNPAz (ORCPT + 99 others); Thu, 14 Mar 2019 11:00:55 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:45998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbfCNPAy (ORCPT ); Thu, 14 Mar 2019 11:00:54 -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 19A6DA78; Thu, 14 Mar 2019 08:00:54 -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 254A73F59C; Thu, 14 Mar 2019 08:00:51 -0700 (PDT) Date: Thu, 14 Mar 2019 15:00:48 +0000 From: Patrick Bellasi To: Dietmar Eggemann Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , 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: <20190314150048.td6o3g7ucb7fg2yy@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-2-patrick.bellasi@arm.com> <21171fa0-7fd5-ebbf-dd48-d6668ed563af@arm.com> <20190313151535.q5ivsuywvwkewrk5@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313151535.q5ivsuywvwkewrk5@e110439-lin> 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:15, Patrick Bellasi wrote: > On 12-Mar 13:52, Dietmar Eggemann wrote: > > On 2/8/19 11:05 AM, Patrick Bellasi wrote: [...] > > > + * within each bucket the exact "requested" clamp value whenever all tasks > > > + * RUNNABLE in that bucket require the same clamp. > > > + */ > > > +static inline void uclamp_rq_inc_id(struct task_struct *p, struct rq *rq, > > > + unsigned int clamp_id) > > > +{ > > > + unsigned int bucket_id = p->uclamp[clamp_id].bucket_id; > > > + unsigned int rq_clamp, bkt_clamp, tsk_clamp; > > > > Wouldn't it be easier to have a pointer to the task's and rq's uclamp > > structure as well to the bucket? > > > > - unsigned int bucket_id = p->uclamp[clamp_id].bucket_id; > > + struct uclamp_se *uc_se = &p->uclamp[clamp_id]; > > + struct uclamp_rq *uc_rq = &rq->uclamp[clamp_id]; > > + struct uclamp_bucket *bucket = &uc_rq->bucket[uc_se->bucket_id]; > > I think I went back/forth a couple of times in using pointer or the > extended version, which both have pros and cons. > > I personally prefer the pointers as you suggest but I've got the > impression in the past that since everybody cleared "basic C trainings" > it's not so difficult to read the code above too. > > > The code in uclamp_rq_inc_id() and uclamp_rq_dec_id() for example becomes > > much more readable. > > Agree... let's try to switch once again in v8 and see ;) This is not as straightforward as I thought. We either still need local variables to use with max(), which does not play well with bitfields values, or we have to avoid using it and go back to conditional updates: ---8<--- static inline void uclamp_rq_inc_id(struct task_struct *p, struct rq *rq, unsigned int clamp_id) { struct uclamp_rq *uc_rq = &rq->uclamp[clamp_id]; struct uclamp_req *uc_se = &p->uclamp_se[clamp_id]; struct uclamp_bucket *bucket = &uc_rq->bucket[uc_se->bucket_id]; bucket->tasks++; /* * Local clamping: rq's buckets always track the max "requested" * clamp value from all RUNNABLE tasks in that bucket. */ if (uc_se->value > bucket->value) bucket->value = uc_se->value; if (uc_se->value > READ_ONCE(uc_rq->value)) WRITE_ONCE(uc_rq->value, uc_se->value); } ---8<--- I remember Peter asking for max() in one of the past reviews.. but the code above looks simpler to me too... let see if this time it can be accepted. :) -- #include Patrick Bellasi