Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7548177imu; Tue, 22 Jan 2019 07:44:24 -0800 (PST) X-Google-Smtp-Source: ALg8bN5VOGUGOxkMliRmeUEkJ06yUjXzvg5Nhhe42ZRZE1UcnN3baXYcAvszhpeczS+L82CpkB1N X-Received: by 2002:a17:902:b093:: with SMTP id p19mr34615815plr.135.1548171864626; Tue, 22 Jan 2019 07:44:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548171864; cv=none; d=google.com; s=arc-20160816; b=jcwpK2zmZ8iFHGheNZ7zRWdLycIHvakMMLIlJ+gdppvbxy6q4P2pgNuDjd2wBGqKfC wsBnzQetqThaqgSGLn1owEWP/BbdwBMe6E1sglhxITfJxlR7doEsrxTHJsrMuLBbKF6a 2Cw3bNFwZFqhtQ26+KmqH6ptsQ1WH6T0Iq7osFrK3fYhZPCQ4G3lGPKBIqP1RHP3o8DP npeL1lr7EqQESMRQTZV2RYoV/nlJUhXVl0zXH1UotGoRjbobMHS+3B8iS03lQSPSpz/i IFi/ciUGhwDOepXELfdKYCJ0+4+odJx+nqK7yMaVvIyGAsUPvQMCOVxfPIRGBhRtXPKr +GWQ== 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=+Hf5FYeZl1+dBdGDayUZ3hXi4gogC0f9UzbshaCalc8=; b=HcVlAAv1U7ZgKLZMCHVklRGIv7XBp+fQQ6AJb/wSeh10Ei12jVK6YcdGtPs74dVsDY JjFVYIoS1b3aXLuzlAcz/k6GwAM7no+fcQ1t2HqB88g81ve4+QnBv1MQwAq2JxJh9fJ6 6BIZ0eDeotMbS74QiwhnTcjD8Kc7asSjJt9lbTJWDLCo/89g+qbhlUZS7uUKFvWpPg61 CKvGQmvcyYjgYt0gAdjicqJqhrYQKrJX6Ja3nFA8cZF1BlYtrKtJJDp0njzrON2+VN+l ZoAfIYy0KvQv5q+Iu/r6mwH2vZje4zI3W1N1PLP9HmHxi20CuZKL6x+zodIXh0Oe/z8v XdCA== 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 92si16005021pld.84.2019.01.22.07.44.08; Tue, 22 Jan 2019 07:44:24 -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 S1729098AbfAVPlg (ORCPT + 99 others); Tue, 22 Jan 2019 10:41:36 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56216 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728580AbfAVPlg (ORCPT ); Tue, 22 Jan 2019 10:41:36 -0500 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 4EE1BA78; Tue, 22 Jan 2019 07:41:35 -0800 (PST) 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 5AB013F589; Tue, 22 Jan 2019 07:41:32 -0800 (PST) Date: Tue, 22 Jan 2019 15:41:29 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v6 07/16] sched/core: uclamp: Add system default clamps Message-ID: <20190122154129.mxnpgaoxnccbjbch@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-8-patrick.bellasi@arm.com> <20190122135644.GP27931@hirez.programming.kicks-ass.net> <20190122144329.ziimv6fejwvky7yb@e110439-lin> <20190122151317.GH13777@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190122151317.GH13777@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-Jan 16:13, Peter Zijlstra wrote: > On Tue, Jan 22, 2019 at 02:43:29PM +0000, Patrick Bellasi wrote: > > On 22-Jan 14:56, Peter Zijlstra wrote: > > > On Tue, Jan 15, 2019 at 10:15:04AM +0000, Patrick Bellasi wrote: > > > > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > > > index 84294925d006..c8f391d1cdc5 100644 > > > > --- a/include/linux/sched.h > > > > +++ b/include/linux/sched.h > > > > @@ -625,6 +625,11 @@ struct uclamp_se { > > > > unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > > > unsigned int mapped : 1; > > > > unsigned int active : 1; > > > > + /* Clamp bucket and value actually used by a RUNNABLE task */ > > > > + struct { > > > > + unsigned int value : bits_per(SCHED_CAPACITY_SCALE); > > > > + unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > > > + } effective; > > > > > > I am confuzled by this thing.. so uclamp_se already has a value,bucket, > > > which per the prior code is the effective one. > > > > > > Now; I think I see why you want another value; you need the second to > > > store the original value for when the system limits change and we must > > > re-evaluate. > > > > Yes, that's one reason, the other one being to properly support > > CGroup when we add them in the following patches. > > > > Effective will always track the value/bucket in which the task has > > been refcounted at enqueue time and it depends on the aggregated > > value. > > > > Should you not update all tasks? > > > > That's true, but that's also an expensive operation, that's why now > > I'm doing only lazy updates at next enqueue time. > > Aaah, so you refcount on the original value, which allows you to skip > fixing up all tasks. I missed that bit. Right, effective is always tracking the bucket we refcounted at enqueue time. We can still argue that, the moment we change a clamp, a task should be updated without waiting for a dequeue/enqueue cycle. IMO, that could be a limitation only for tasks which never sleep, but that's a very special case. Instead, as you'll see, in the cgroup integration we force update all RUNNABLE tasks. Although that's expensive, since we are in the domain of the "delegation model" and "containers resources control", there it's probably more worth to pay than here. > > Do you think that could be acceptable? > > Think so, it's a sysctl poke, 'nobody' ever does that. Cool, so... I'll keep lazy update for system default. -- #include Patrick Bellasi