Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1188718ybi; Tue, 16 Jul 2019 10:56:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdf+anY0BZ2ZKkN9i5Rkt7zwcUu/nFYgTyf1dXRGE+zXHRvntsDHtNfZ4wWP+J5rqB9Wgd X-Received: by 2002:a63:24a:: with SMTP id 71mr11056540pgc.273.1563299785665; Tue, 16 Jul 2019 10:56:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563299785; cv=none; d=google.com; s=arc-20160816; b=CS2uyFXXjbY6SQs2uxvTsYSw23ah7lKrJbm08j71dQeZjgMv1TqlJIRfKLPQcRJWnx stQCQv0/5b5FzYRUePTOudqboLFZq5x/P8hdPTgZlCHJ8JQ3n78UEz2rAkHPw4ehKjyt U/tufBfpFqNm4G264CRlTrtuFhem1BgaX6Gn/zQTmY8QdE+E3SlF9DzgDiaNMLMKgMOJ DUy9xlPtijLTn7ylkIHoaQ9bxrIFpLMluq/qHvqzYN1M514tb01jJPf9+WPG+8Z1VnII OfqjpQFdyYxgA4rFIlpSCGYVH0IBkNcd3TfBxMGj1ZzV6i7gAuF3HyRC+JCah/H9WO8K ynYg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=HNwElqe5/EhPBRdUXCBedfGAAQyfaPzOOe0BCgSydRs=; b=KYoCms/Xf0f3qUoU71qnmkjHfpCPP5YhZwi2r8PmL4GIRUcQURqMxof6a/7wYLI7Tv w9kIIP/8a7blKbRSyYO0W3zk/p/XzPzcE4RWYgRZnQHkw9oI5Oqq/LbhDQDkGF1YoAxb w9TMTQ7DDLSnQKO/8PcFmAmRoUjtYREHbEnUOcVJlFFVwxen6POa8IHpYcKydHjO/jsD RgR8tG2/pe3Njyv0YMB6LelcIH+T3eku1VlrvkpIKpT02oYd5KrpR3TIjkI2Q+tbYip1 0/eQ0gswn5OzN4BTWYaLhYgphfCvkyOqYHyMfkTDDZjGuLeGmeNxfxy0bGj8bhPEXNY8 W4Dw== 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 w69si14346457pgd.531.2019.07.16.10.56.07; Tue, 16 Jul 2019 10:56:25 -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 S2387488AbfGPRzr (ORCPT + 99 others); Tue, 16 Jul 2019 13:55:47 -0400 Received: from foss.arm.com ([217.140.110.172]:38298 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725926AbfGPRzr (ORCPT ); Tue, 16 Jul 2019 13:55:47 -0400 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 EDE032B; Tue, 16 Jul 2019 10:55:45 -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 994253F71A; Tue, 16 Jul 2019 10:55:43 -0700 (PDT) Date: Tue, 16 Jul 2019 18:55:42 +0100 From: Patrick Bellasi To: Michal =?utf-8?Q?Koutn=C3=BD?= 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: <20190716175542.p7vs2muslyuez6lq@e110439-lin> References: <20190708084357.12944-1-patrick.bellasi@arm.com> <20190708084357.12944-3-patrick.bellasi@arm.com> <20190715164200.GA30862@blackbody.suse.cz> <20190716140706.vuggfigjlys44lkp@e110439-lin> <20190716152929.GD32540@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190716152929.GD32540@blackbody.suse.cz> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16-Jul 17:29, Michal Koutn? wrote: > 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. Right, I've just added a paragraph to the cpu.uclamp.min documentation. > > 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. Right, the mutex is used only on the cgroup side. That's because the CGroup API can affect multiple tasks running on different CPUs, thus we wanna make sure we don't come up with race conditions. In that path we can also afford to go a bit slower. In the fast path instead we rely on the rq-locks to ensure serialization on RUNNABLE tasks clamp updates. Coming from the __setscheduler_uclamp() side however we don't sync RUNNABLE tasks immediately. We delay the update to next enqueue opportunity. Cheers, Patrick -- #include Patrick Bellasi