Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3728414imc; Thu, 14 Mar 2019 04:05:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwc+eCMFUVUykDEZP8h3kBAkhEjvcac8v1ZQtX3MS8XApmgfBoYWP6YbHRwIgqFIr+64uWE X-Received: by 2002:a17:902:2d01:: with SMTP id o1mr3712946plb.155.1552561504400; Thu, 14 Mar 2019 04:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552561504; cv=none; d=google.com; s=arc-20160816; b=e5w0JH3z5xOw0a8/63cdola9iXYAOVhGisOseKIk3iqNtUyazvIiNc/cmw11Ct1ZU+ HsUO3ZVOreY3Z7hb8+Nki0Y7JHeftYiljncKr76dFOmQYe20MkdO+DjYjLU0I9ipU3lL gcRUf5P9ZkkTeSmiov0krC0T14Y89/xssQQ71AdMIA1xB0MrYdQoxNAkLYpeI94KJjP5 qBPaDqbCcKIfsqz8lqISFBfqz5C9L9QdFElCMMFRyOwm+YO5cM4g2W7mEGcYifXMMtSN 6Egp9f+DqLM4m+j2nVTNhRgtRTrqgtRX8xlNGIltGE3Ph7gtsNjxvEbOkfOsPxkUu1AQ O2Og== 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=1V0zYv3F2aqc0Msf+lOeSLfiEThYdSJEW874srsVwm8=; b=denCCK64iznC77c0qpKn3EYDd7ZZ1G8wZf6o+XHNJchJMJ23lti+S1hB1rYMDtcY6W Bt22E1xskLqQwQqo6GxvCfTNMue3lxHwHNIDUcDrTxInhK7KD2GSsz4VT7ufJ4DDp3RD bWpvSEFvU6XbBFXjzVa/zSu8umq0Flhm4JBJE06G+xpsxVC67EQP5o1fL2nyyyBHlJjn m3MUDgkHAB2NKRNTB0TjI4k15V48wqVRkOeDE1MInerMqFSXWVgTCGLGpI/UfGNb25hS wwx4uiyCTPCN221dBhFWa7PlAu+SumgLPVmdWTwqmaz7bKnZnW/cRTehHOb1nqdFvQ5O fhEw== 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 d19si12206404pgv.522.2019.03.14.04.04.48; Thu, 14 Mar 2019 04:05:04 -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 S1727474AbfCNLDg (ORCPT + 99 others); Thu, 14 Mar 2019 07:03:36 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42338 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727421AbfCNLDg (ORCPT ); Thu, 14 Mar 2019 07:03:36 -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 A16D2374; Thu, 14 Mar 2019 04:03:35 -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 AC96B3F71D; Thu, 14 Mar 2019 04:03:32 -0700 (PDT) Date: Thu, 14 Mar 2019 11:03:30 +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: <20190314110330.rshrdeoxgzt6pk5a@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-2-patrick.bellasi@arm.com> <20190313135238.GC5922@hirez.programming.kicks-ass.net> <20190313155954.jse2tyn5iqxm6wle@e110439-lin> <20190313193056.GP2482@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313193056.GP2482@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:30, Peter Zijlstra wrote: > On Wed, Mar 13, 2019 at 03:59:54PM +0000, Patrick Bellasi wrote: > > On 13-Mar 14:52, Peter Zijlstra wrote: > > > > +static inline void uclamp_rq_dec_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; > > > > + > > > > + SCHED_WARN_ON(!rq->uclamp[clamp_id].bucket[bucket_id].tasks); > > > > + if (likely(rq->uclamp[clamp_id].bucket[bucket_id].tasks)) > > > > + rq->uclamp[clamp_id].bucket[bucket_id].tasks--; > > > > + > > > > + /* > > > > + * Keep "local clamping" simple and accept to (possibly) overboost > > > > + * still RUNNABLE tasks in the same bucket. > > > > + */ > > > > + if (likely(rq->uclamp[clamp_id].bucket[bucket_id].tasks)) > > > > + return; > > > > > > (Oh man, I hope that generates semi sane code; long live CSE passes I > > > suppose) > > > > What do you mean ? > > that does: 'rq->uclamp[clamp_id].bucket[bucket_id].tasks' three times in > a row. And yes the compiler _should_ dtrt, but.... Sorry, don't follow you here... but it's an interesting point. :) The code above becomes: if (__builtin_expect(!!(rq->uclamp[clamp_id].bucket[bucket_id].tasks), 1)) return; Are you referring to the resolution of the memory references, i.e 1) rq->uclamp 2) rq->uclamp[clamp_id] 3) rq->uclamp[clamp_id].bucket[bucket_id] ? By playing with: https://godbolt.org/z/OPLpyR I can see that this simplified version: ---8<--- #define BUCKETS 5 #define CLAMPS 2 struct uclamp { unsigned int value; struct bucket { unsigned int value; unsigned int tasks; } bucket[BUCKETS]; }; struct rq { struct uclamp uclamp[CLAMPS]; }; void uclamp_rq_dec_id(struct rq *rq, int clamp_id, int bucket_id) { if (__builtin_expect(!!(rq->uclamp[clamp_id].bucket[bucket_id].tasks), 1)) return; rq->uclamp[clamp_id].bucket[bucket_id].tasks--; } ---8<--- generates something like: ---8<--- uclamp_rq_dec_id: sxtw x1, w1 add x3, x1, x1, lsl 1 lsl x3, x3, 2 sub x3, x3, x1 lsl x3, x3, 2 add x2, x3, x2, sxtw 3 add x0, x0, x2 ldr w1, [x0, 8] cbz w1, .L4 ret .L4: mov w1, -1 str w1, [x0, 8] ret ---8<--- which looks "sane" and quite expected, isn't it? -- #include Patrick Bellasi