Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2170481imm; Thu, 9 Aug 2018 08:24:36 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyfAuowmA2CLaam3ZUdh2W4yV9ClISzn9HXfiyreGfwUDA1MYPM+rZ0K2GhljzEpLR8+S7w X-Received: by 2002:a62:e0d5:: with SMTP id d82-v6mr2850549pfm.59.1533828276394; Thu, 09 Aug 2018 08:24:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533828276; cv=none; d=google.com; s=arc-20160816; b=eB+8XTGBJx1JTF8keKRJLYSmD3PDSwQUM60pTh6bbaRVDoV5CznucmtOA6CmjJ3Fhm 6YBODEN9qm3QfAoH96GUn2HPPNSfTLCEclOEXgHPPZ0x/O6moQD7ojkZ9Og8in1e/wZT A/0rMFW/3iwAM/ioTpOMTJWIDWsvCRwGWVhCRjDrtecqeThrTg9V2cy4nyxw50wIhANS YHp0mYABXkh8GS6KMFqgrxui8mcprDShlLhF3JLAbxDSOW7bB8BA0M9ohrYlWzAj3rwg HVxh1ZJbQhEkMkspKdmoCGL8kgozC+zVbXwqZOBaYEyJp0qzD+Ptj1kX3ICizbu+7Yog VoJQ== 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:arc-authentication-results; bh=AZ2v8Z2YEI50ln73SnEmZAPRHE4rJ/0V/zeBBpJNzks=; b=YCPnKLc/M1jqlK9I9LGO9UVkuJIidIDfSNizg+JGSPNZxaYy1nO4UmsmrDXNIvVeSW 64KId3YIg60wwsKBaNUiWA/O4gQOXoFAk3pEoG3eBfr8M4AMtdUX1ZRFGqOgzfNwF5qM W911cp/oByAMJ8UF7vzyAb1+Ju1Hb3SYX2y9Nj6wzCSMhAhwTzUNDW007RH+htJLEUiF 1QxAzHS0tnhbBQggzq2X+6kcOrKmZ3IT6xGqwzzHIyfDvmBJ0hBt25uoDohvN3p+uV1Y Oj1LtB+kY75XGVJEgpN0Z909v6BJzlraWm/G0NaQ59ZhOUt62AxG8FM1/+7FuO1Vb7Qe E3Dw== 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 d192-v6si7380272pgc.504.2018.08.09.08.24.21; Thu, 09 Aug 2018 08:24:36 -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 S1732312AbeHIRsp (ORCPT + 99 others); Thu, 9 Aug 2018 13:48:45 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730839AbeHIRsp (ORCPT ); Thu, 9 Aug 2018 13:48:45 -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 4D1CA7A9; Thu, 9 Aug 2018 08:23:21 -0700 (PDT) Received: from darkstar (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 968353F5B3; Thu, 9 Aug 2018 08:23:17 -0700 (PDT) Date: Thu, 9 Aug 2018 16:23:13 +0100 From: Patrick Bellasi To: Juri Lelli Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping Message-ID: <20180809152313.lewfhufidhxb2qrk@darkstar> References: <20180806163946.28380-1-patrick.bellasi@arm.com> <20180806163946.28380-2-patrick.bellasi@arm.com> <20180807123550.GA3062@localhost.localdomain> <20180809091427.4p2c4fbxocpkjaby@darkstar> <20180809095043.GC22465@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180809095043.GC22465@localhost.localdomain> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09-Aug 11:50, Juri Lelli wrote: > On 09/08/18 10:14, Patrick Bellasi wrote: > > On 07-Aug 14:35, Juri Lelli wrote: > > > On 06/08/18 17:39, Patrick Bellasi wrote: [...] > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot > > time parameter to relax this check > > It seems to me that this might work well with that the intended usage of > the interface that you depict above. SMS only (or any privileged user) > will be in control of how groups are configured, so no problem for > normal users. Yes, well... apart normal users still getting a -ENOSPC is they are requesting one of the not pre-configured clamp values. Which is why the following bits can be helpful. > > 2) add discretization support to clamp groups allocation > > And this might also work well if we feel that we don't want to restrict > usage of the interface to admin only, however... > > > This second feature specifically, will ensure that clamp values are > > always mapped into one of the available clamp groups. While the exact > > clamp value can always be used for tasks placement biasing, when it > > comes to frequency selection biasing, depending on concurrently > > running tasks, you can end up with an effective clamp value which is a > > rounded up. > > what I'm not so sure about is that we might lose in flexibility if the > number of available discrete clamp groups is too small compared to the > number of available OPP on the platform. Regarding this concern, I would say that we should consider that, for frequency biasing, we are in general not interested in nailing down the single 1% difference and/or exact OPP capacities A certain coarse grained resolution is usually acceptable for many different reasons: a) schedutil already uses a 20% margin which can potentially eclipse few OPP when we scale up/down b) tasks/CPUs utilization are good enough but never exact and precise values c) reducing the number of OPP switches could have some benefits on stability/latencies d) clamping is actually defining minimum/maximum preferred values, is not to be considered a tool for "precise control" All that considered, I would say that maybe a 5% resolution could still be considered an acceptable _worst case_ rounding since we don't have always to round up to the next 5%. For example, if we have: - TaskA: util_min=41% - TaskB: util_nin=44% they will be both accounted in the 40-45% clamp group but the clamp group value can be modulated at run-time depending on RUNNABLE tasks. When TaskA is running alone, we can still set util_min to 41%, while we will use 44% (not 45%) when TaskB is (also) running. It's worth to notice that we pre-allocated at compile time 20 clamp groups, but not necessarily all of them will be used at run-time. Indeed, we will still use a policy where only the actual required values are allocated at the beginning of the clamps map, thus optimizing max updates. -- #include Patrick Bellasi