From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A378CC43381 for ; Wed, 13 Mar 2019 11:38:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 76BB42147C for ; Wed, 13 Mar 2019 11:38:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726337AbfCMLiH (ORCPT ); Wed, 13 Mar 2019 07:38:07 -0400 Received: from foss.arm.com ([217.140.101.70]:56498 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725888AbfCMLiG (ORCPT ); Wed, 13 Mar 2019 07:38:06 -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 328CB80D; Wed, 13 Mar 2019 04:38:06 -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 3E7753F71D; Wed, 13 Mar 2019 04:38:03 -0700 (PDT) Date: Wed, 13 Mar 2019 11:37:57 +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: <20190313113757.aeaksz5akv6y5uep@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-2-patrick.bellasi@arm.com> <20190312152059.GA5922@hirez.programming.kicks-ass.net> <20190312155043.vj3fiutnsovjti2x@e110439-lin> <20190313081958.GA5996@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313081958.GA5996@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 09:19, Peter Zijlstra wrote: > On Tue, Mar 12, 2019 at 03:50:43PM +0000, Patrick Bellasi wrote: > > On 12-Mar 16:20, Peter Zijlstra wrote: > > > On Fri, Feb 08, 2019 at 10:05:40AM +0000, Patrick Bellasi wrote: > > > > +/* Integer ceil-rounded range for each bucket */ > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > +#define UCLAMP_BUCKET_DELTA ((SCHED_CAPACITY_SCALE / UCLAMP_BUCKETS) + 1) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > simply do not match. Right, that don't match when UCLAMP_BUCKETS is a divider of SCHED_CAPACITY_SCALE, i.e. when we use 8 or 16 buckets. > > > Uhm, should that not me ((x+y-1)/y), aka. DIV_ROUND_UP(x,y) ? > > > > Well, there is certainly some rounding to be done... > > > > > The above would give 4 for 9/3, which is clearly buggered. > > > > .. still the math above should work fine within the boundaries we > > define for UCLAMP_BUCKET_DELTA (5..20 groups) and considering that > > SCHED_CAPACITY_SCALE will never be smaller then 1024. > > That's a very poor reason to write utter nonsense :-) > > > The above is designed to shrink the topmost bucket wrt all the others > > but it will never be smaller than ~30%. > > 30% sounds like a lot, esp. for this range. Well, that 30% is really just ~16 utiliation units on a scale of 1024 when buckets have a size of 52. Still, yes, we can argue that's big but that's also the same error generated by DIV_ROUND_UP() when UCLAMP_BUCKETS is not 8 or 16. > > Here are the start values computed for each bucket using the math > > above and the computed shrinking percentage for the topmost bucket: > > If you use a regular rounding, the error is _much_ smaller: > > $ for ((x=5;x<21;x++)) ; do let d=(1024+x/2)/x; let s=(x-1)*d; let e=1024-s; let p=100*(d-e)/d; echo $x $d $s $e $p%; done ^^^^^^^^^^^^^ > 5 205 820 204 0% > 6 171 855 169 1% > 7 146 876 148 -1% > 8 128 896 128 0% > 9 114 912 112 1% > 10 102 918 106 -3% > 11 93 930 94 -1% > 12 85 935 89 -4% > 13 79 948 76 3% > 14 73 949 75 -2% > 15 68 952 72 -5% > 16 64 960 64 0% > 17 60 960 64 -6% > 18 57 969 55 3% > 19 54 972 52 3% > 20 51 969 55 -7% > > Funnily enough, we have a helper for that too: DIV_ROUND_CLOSEST(). ^^^^^^^^^^^^^^^^^^^^ This is different than DIV_ROUND_UP() and actually better across the full range. > Now, if we go further, the error will obviously increase because we run > out of precision, but even there, regular rounding will be better than > either floor or ceil. I don't think we will have to cover other values in the further but I agree that this "closest rounding" is definitively better. Thanks for spotting it, will update in v8. -- #include Patrick Bellasi