Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1021675ybi; Tue, 16 Jul 2019 08:30:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzx6fNbmeUi4ByuMF4mEyGPEMv47AcYnexMEoAFO1aZJn7Jub+pyWJ2qdgceYxBKht5iCj0 X-Received: by 2002:a17:90b:f0e:: with SMTP id br14mr37269002pjb.117.1563291033324; Tue, 16 Jul 2019 08:30:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563291033; cv=none; d=google.com; s=arc-20160816; b=HbwDfC/cpvX9JxLiGv0SXO5W0Gv+83xXNtIk2/MNnaLVkPGwsfF67BIUsHL63vwkuU dbFHrsSlgRtadTXUjUimnKN6aPBT6B5zKHR+07zh7hn/rtvxOwy5Z9R+9W1gfTnhz0wp hOfD89LZfArB7Qp0OgnTL7ecCsuv0rZ/uUEhu9GjKFFCIF8p2HVPTjDRZiXLtrYu9sno cwaU0Qvw91hDX61+Nzub7oLZ/2LywWE67R6gDy2v+2J3hFMd2H73yFKuiXPC9jxT8YjE nADLC0zNd416duv1Et0HSper1MEQW5Ez6MvIAL8tOj20psLMstbIJQ7IvyFQDdC8zclP eTjQ== 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=2DIcvN0jaD27sdj4LtPokXJq8wZ520JecZegYNxv4Tg=; b=HgttMQjBJSeR/t/x11fI4nM2VhJIml27RyxjRfv4GZ3ML987L/0otxYZl+bHjz9nKC 2Dod2A6uhEj9jahT09/0Ff9hrUKobD8vFe+6x1TBbXw0IPq67KY84Zy+QxobDxB/ex84 wa7s2pwl4PwauX1zu+GuVDXdky2HW1O2siQgubfly/+xIiyvLVbgQUX/647d7p1uMQAs IL6mmBn57qqodxcxATshoABoLrPR5+w8euTmX9mDh9s51FnDPFzlAzE5xz3+zHsJrJWj F4s7doqXUbqo3vVsXyVMS6d2yFMJ3gd5AJKNFigaLRDFaAaLubwmuUvfgtGPTG322dK4 BcBw== 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 c139si22570864pfb.140.2019.07.16.08.30.17; Tue, 16 Jul 2019 08:30:33 -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 S1728695AbfGPP3e (ORCPT + 99 others); Tue, 16 Jul 2019 11:29:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:44400 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728004AbfGPP3d (ORCPT ); Tue, 16 Jul 2019 11:29:33 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3E0B8AF1D; Tue, 16 Jul 2019 15:29:32 +0000 (UTC) Date: Tue, 16 Jul 2019 17:29:30 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Patrick Bellasi Cc: Alessio Balsini , Dietmar Eggemann , Morten Rasmussen , Quentin Perret , Joel Fernandes , Paul Turner , Steve Muckle , Suren Baghdasaryan , Todd Kjos , Peter Zijlstra , "Rafael J . Wysocki" , Tejun Heo , Vincent Guittot , Viresh Kumar , Juri Lelli , Ingo Molnar , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v11 2/5] sched/core: uclamp: Propagate parent clamps Message-ID: <20190716152929.GD32540@blackbody.suse.cz> References: <20190708084357.12944-1-patrick.bellasi@arm.com> <20190708084357.12944-3-patrick.bellasi@arm.com> <20190715164200.GA30862@blackbody.suse.cz> <20190716140706.vuggfigjlys44lkp@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190716140706.vuggfigjlys44lkp@e110439-lin> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 16, 2019 at 03:07:06PM +0100, Patrick Bellasi wrote: > That note comes from the previous review cycle and it's based on a > request from Tejun to align uclamp behaviors with the way the > delegation model is supposed to work. I saw and hopefully understood that reasoning -- uclamp.min has the protection semantics and uclamp.max the limit semantics. However, what took me some time to comprehend when the effected uclamp.min and uclamp.max cross over, i.e. that uclamp.min is then bound by uclamp.max (besides parent's uclamp.min). Your commit message explains that and I think it's relevant for the kernel docs file itself. > You right, the synchronization is introduced by a later patch: > > sched/core: uclamp: Update CPU's refcount on TG's clamp changes I saw that lock but didn't realize __setscheduler_uclamp() touches only task's struct uclamp_se, none of task_group's/css's (which is under uclamp_mutex). That seems correct.