Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4003109ybc; Tue, 26 Nov 2019 02:08:43 -0800 (PST) X-Google-Smtp-Source: APXvYqzirmJ9J3AfF7wnraQpYPLaaTQECEGxMtWJPgH7IZYlWw1jkjlUVe5Pkg0nkjQwpswK+dcq X-Received: by 2002:a05:6402:311b:: with SMTP id dc27mr1492419edb.106.1574762923162; Tue, 26 Nov 2019 02:08:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574762923; cv=none; d=google.com; s=arc-20160816; b=IMOJeNupr4I3j8+j1qQhbHDDWwLUxicHC/XRIKKZTq0ontvtzEMCxOg8QloLujq6rN Gk4e1JZAdJa0zEsWADEZqreViZDY0FSzi2VXdrobt4r/5APGJ6sTz6ljC1E+Wfzs1Pez bIeLREjXFSTio8y9cBK9xUmvAnKe2h714Gcwb1E4mjCN/ctC+PgnaSjvU3aHoO7X/7GB Af/Po/jZQLOzjKNkMN9mgnoIuZ1b4N8DmKl40AuPmmsR3vbY6h7YjehdPmUmaWnqsqkU pTal7JXuZvk2pUWyJbsPXJKiYFKzZKaSOxBDCOh28vf/3VfJWQPmiDbZgIBmsGufkXtN 4J9g== 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=vKruaZ1yaUDRED+SwOeMOydy1E39ob1ql1jKg0O45zI=; b=myItqZ/K7VE50J4eHB2eZavOIC8iL62UZNFosTStHW1n8ODNkW3HABdgF2ybMHsfnN Uki6ANXLzY9GVH7CLnEnzDGp3T2d93boHkqfc6IjUoG92fIPQXJkr9M/LqKk4LVqmouI No9kXDYRAJvttQMnoXy6zM9pM6boplspqyRPn4gYok2UBrcysP7/iM+l9uxn4yrGgcxh a6OlxXAfDa6J/TtORl2H2QECTuJyfmC2w3boS7ZFurgCvT3wszWP7wUx0diTX8OUsqCG iKFLqzoV9iqLLoIiPLYuWOarO4H6rzMobgOBPQQGdEHtqvXKQzKuKB+USimHYX1qzuUP Q8Ew== 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 q3si6459873eju.242.2019.11.26.02.08.19; Tue, 26 Nov 2019 02:08:43 -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 S1727705AbfKZKGn (ORCPT + 99 others); Tue, 26 Nov 2019 05:06:43 -0500 Received: from foss.arm.com ([217.140.110.172]:60566 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727482AbfKZKGn (ORCPT ); Tue, 26 Nov 2019 05:06:43 -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 64F5E30E; Tue, 26 Nov 2019 02:06:42 -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 208703F52E; Tue, 26 Nov 2019 02:06:41 -0800 (PST) Date: Tue, 26 Nov 2019 10:06:38 +0000 From: Qais Yousef To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@kernel.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, patrick.bellasi@matbug.net, qperret@google.com, morten.rasmussen@arm.com Subject: Re: [PATCH 3/3] sched/fair: Consider uclamp for "task fits capacity" checks Message-ID: <20191126100638.pbcxnii67fihkb3g@e107158-lin.cambridge.arm.com> References: <20191120175533.4672-1-valentin.schneider@arm.com> <20191120175533.4672-4-valentin.schneider@arm.com> <20191124222051.kbb62phfsln5ixg4@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/25/19 17:33, Valentin Schneider wrote: > With cgroups, I do recall something about allowing the cgroup *knobs* to be > inverted, but AFAICT that gets sanitized when it trickles down to the > scheduler via cpu_util_update_eff(): > > eff[UCLAMP_MIN] = min(eff[UCLAMP_MIN], eff[UCLAMP_MAX]); I missed that we cap here too. > > So I don't see how inversion could happen within uclamp_task_util(). > Patrick, any chance you could light up my torch? I think I am equally confused now. A clarification that can help improving the comment would be useful. Thanks -- Qais Yousef