Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3338465ybl; Sun, 12 Jan 2020 15:38:35 -0800 (PST) X-Google-Smtp-Source: APXvYqwhVSLyxqjrmwzh8wO5YyrOQP6yhw+88jMRptCjid8Az7PMsGbQAAdgLektC515v2L5ZGs+ X-Received: by 2002:a05:6808:907:: with SMTP id w7mr10796638oih.137.1578872315794; Sun, 12 Jan 2020 15:38:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578872315; cv=none; d=google.com; s=arc-20160816; b=wjOvWI90DpWq8GlTS5YvqPLqMr8vs7+eRJeYNJyMgB/Bt6w24zp9te749K4WAyl24H HDd/VkFjQj4YA57ZannhUgirw+3KVmbhDVE/VBPsnI47m4AutK09hAEp/G5AzXeCvekV jqVRvoS5kL6mHOEgXE6yJmFCMuGAoaCG1slZ7g5vX4wUBj9wVus7nfXPxkFcrZ761JiY 9HiOySq920vfGrOrs1+nVHVldbtF/38/PZl8awGYa/H5BjR1ts31dU+nODV+TZJjmayN UsAJefBW9dCEK8+52Hd+n31OyM26L5+A1E0W/mwEDUMx63iFIqagqV06n/adpMKiohvA V/hw== 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=8dtJ/Y5Z4qsKxl/5qqXibw5OV8XSDqxtaGISZ7MW6iY=; b=hauoy0VLm3dYb29T5SfNi8Loux3OPvAbeDrrkC7yj2IuwtuUteHLEWjAJ8vC/nJ7+V sc8ZIZ1M/AFPaNuCdNaqErgNui+IPjy2xXhoyR9eT1XPYZqkTCcgv0guYqTPPEZ4t2Zl YNq/E2zM+pHgfAGe4+9r+iShxIYZY6AVeiBtyBbwdF6B2NJEHJip2n7USRkgp8r5qJQA mlFXAbRqIflXtNih5JoDCUCvWIhMZhyfGO6qLDPDuIrdoQvsTxjpGCPAkfruudXZhEV0 nN8E1SNZT+/8MOD+vGPhZj76uv2iX9ExQKKluJUs75ZOgH0GAFfxZUPQI7nC5VHXjIb5 hIAA== 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 101si5620858otm.168.2020.01.12.15.37.55; Sun, 12 Jan 2020 15:38:35 -0800 (PST) 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 S2387495AbgALXfe (ORCPT + 99 others); Sun, 12 Jan 2020 18:35:34 -0500 Received: from foss.arm.com ([217.140.110.172]:33038 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727323AbgALXfe (ORCPT ); Sun, 12 Jan 2020 18:35:34 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4FB7B30E; Sun, 12 Jan 2020 15:35:31 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4F7D13F534; Sun, 12 Jan 2020 15:35:29 -0800 (PST) Date: Sun, 12 Jan 2020 23:35:27 +0000 From: Qais Yousef To: Peter Zijlstra Cc: Ingo Molnar , Dietmar Eggemann , Steven Rostedt , Luis Chamberlain , Kees Cook , Iurii Zaikin , Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , valentin.schneider@arm.com, qperret@google.com, Patrick Bellasi , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] sched/rt: Add a new sysctl to control uclamp_util_min Message-ID: <20200112233526.wmrq5i6hqqez4oby@e107158-lin.cambridge.arm.com> References: <20191220164838.31619-1-qais.yousef@arm.com> <20200108134448.GG2844@hirez.programming.kicks-ass.net> <20200109130052.feebuwuuvwvm324w@e107158-lin.cambridge.arm.com> <20200110133956.GL2844@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200110133956.GL2844@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/10/20 14:39, Peter Zijlstra wrote: > On Thu, Jan 09, 2020 at 01:00:58PM +0000, Qais Yousef wrote: > > On 01/08/20 14:44, Peter Zijlstra wrote: > > > On Fri, Dec 20, 2019 at 04:48:38PM +0000, Qais Yousef wrote: > > > > RT tasks by default try to run at the highest capacity/performance > > > > level. When uclamp is selected this default behavior is retained by > > > > enforcing the uclamp_util_min of the RT tasks to be > > > > uclamp_none(UCLAMP_MAX), which is SCHED_CAPACITY_SCALE; the maximum > > > > value. > > > > > > > > See commit 1a00d999971c ("sched/uclamp: Set default clamps for RT tasks"). > > > > > > > > On battery powered devices, this default behavior could consume more > > > > power, and it is desired to be able to tune it down. While uclamp allows > > > > tuning this by changing the uclamp_util_min of the individual tasks, but > > > > this is cumbersome and error prone. > > > > > > > > To control the default behavior globally by system admins and device > > > > integrators, introduce the new sysctl_sched_rt_uclamp_util_min to > > > > change the default uclamp_util_min value of the RT tasks. > > > > > > > > Whenever the new default changes, it'd be applied on the next wakeup of > > > > the RT task, assuming that it still uses the system default value and > > > > not a user applied one. > > > > > > This is because these RT tasks are not in a cgroup or not affected by > > > cgroup settings? I feel the justification is a little thin here. > > > > The uclamp_min for RT tasks is always hardcoded to 1024 at the moment. So even > > if they belong to a cgroup->uclamp_min = 0, they'll still run at max frequency, > > no? > > Argh, this is that counter intuitive max aggregate nonsense biting me. Yeah I thought we already have a mechanism to control this, until you try to do it then you find out we don't. Not conveniently at least. Are you okay with the sysctl to tune this behavior then? Thanks -- Qais Yousef