Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6369358imu; Mon, 21 Jan 2019 07:46:22 -0800 (PST) X-Google-Smtp-Source: ALg8bN5RUneYqMW8V+bG0sY25/5LQ2tqlw4gGvitoGywJmumSUIqUdoLNOY2FIEXhunX0+rZ1h1w X-Received: by 2002:a62:868b:: with SMTP id x133mr31674550pfd.252.1548085582061; Mon, 21 Jan 2019 07:46:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548085582; cv=none; d=google.com; s=arc-20160816; b=jFABCOb1n0uWv1nVX6xjRTmUGrZr1ghqRWEl/a8/aRe8ribxswfG4zWVs/jYUayazk ug+sb/q7z8/7yAw4pc7TNF3QAF2KBsYQa1Ij2UFY4GGim/3AMy7oECrcf6kXOqc/7JFK 0FMBw/4+4ZeaqPVt5ageBE9CKmOMPcOfs7Qt3qt13qpseOcPs22hRqudYe1wjQlIaLL7 K5fpJORoNp74F1V50s+fHArEnGK37oLPGb5axPkmYZmykW8kjDFsonMYS8PYUtDxSQ3D YPbSOPu7yUpSwbHB9fQ1+DAVyULmi52rkbjkVJ7FnzcLzpTRpGOiJQ3WNuSflk9LS7+D QGhg== 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=XGJGd2DIKnhN33iOx0p7Tdx6lLrqwSzsEnCKoJhqrQ4=; b=KDi+rjevXc3z58AJcb4BzuaYOXUGWYjMM3wsqJ4+YWJwMmu3oLvVks1RsgmXHtZ70X 6ldptFILccwXO/uDTvUlR/NVBxLVpExs/YmpHkCBp22LwfqUJMmBkCT4XM7hhY+qWOAG t3R0qleqhAQ3J7v5GDirK45+o/0giFso/o5FRySvLChiEt5UTw0Ln0tdaRrkc0AjBVl4 eIXw8SqD7804PdHQd7HCpfjKAet1tXAaDmtvaJGmwXizQOzyvZ2YOvYT2eA31iYcBQD8 YKp2kxvLpFM5Kt4j9vts60dlCg2BFzs0HdJV6xnpGr/wwgqCsktyW4pxdKifG86rRNc9 V5Cw== 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 d2si13129462pla.81.2019.01.21.07.46.05; Mon, 21 Jan 2019 07:46:22 -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 S1730345AbfAUPoS (ORCPT + 99 others); Mon, 21 Jan 2019 10:44:18 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:37242 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729534AbfAUPoS (ORCPT ); Mon, 21 Jan 2019 10:44:18 -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 B8666EBD; Mon, 21 Jan 2019 07:44:17 -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 BBA3C3F5C1; Mon, 21 Jan 2019 07:44:14 -0800 (PST) Date: Mon, 21 Jan 2019 15:44:12 +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 05/16] sched/core: uclamp: Update CPU's refcount on clamp changes Message-ID: <20190121154412.fak2t2iquj3aixtu@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-6-patrick.bellasi@arm.com> <20190121153308.GL27931@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190121153308.GL27931@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 21-Jan 16:33, Peter Zijlstra wrote: > On Tue, Jan 15, 2019 at 10:15:02AM +0000, Patrick Bellasi wrote: > > > +static inline void > > +uclamp_task_update_active(struct task_struct *p, unsigned int clamp_id) > > +{ > > + struct rq_flags rf; > > + struct rq *rq; > > + > > + /* > > + * Lock the task and the CPU where the task is (or was) queued. > > + * > > + * We might lock the (previous) rq of a !RUNNABLE task, but that's the > > + * price to pay to safely serialize util_{min,max} updates with > > + * enqueues, dequeues and migration operations. > > + * This is the same locking schema used by __set_cpus_allowed_ptr(). > > + */ > > + rq = task_rq_lock(p, &rf); > > + > > + /* > > + * Setting the clamp bucket is serialized by task_rq_lock(). > > + * If the task is not yet RUNNABLE and its task_struct is not > > + * affecting a valid clamp bucket, the next time it's enqueued, > > + * it will already see the updated clamp bucket value. > > + */ > > + if (!p->uclamp[clamp_id].active) > > + goto done; > > + > > + uclamp_cpu_dec_id(p, rq, clamp_id); > > + uclamp_cpu_inc_id(p, rq, clamp_id); > > + > > +done: > > + task_rq_unlock(rq, p, &rf); > > +} > > > @@ -1008,11 +1043,11 @@ static int __setscheduler_uclamp(struct task_struct *p, > > > > mutex_lock(&uclamp_mutex); > > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) { > > - uclamp_bucket_inc(&p->uclamp[UCLAMP_MIN], > > + uclamp_bucket_inc(p, &p->uclamp[UCLAMP_MIN], > > UCLAMP_MIN, lower_bound); > > } > > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) { > > - uclamp_bucket_inc(&p->uclamp[UCLAMP_MAX], > > + uclamp_bucket_inc(p, &p->uclamp[UCLAMP_MAX], > > UCLAMP_MAX, upper_bound); > > } > > mutex_unlock(&uclamp_mutex); > > > But.... __sched_setscheduler() actually does the whole dequeue + enqueue > thing already ?!? See where it does __setscheduler(). This is slow-path accounting, not fast path. There are two refcounting going on here: 1) mapped buckets: clamp_value <--(M1)--> bucket_id 2) RUNNABLE tasks: bucket_id <--(M2)--> RUNNABLE tasks in a bucket What we fix here is the refcounting for the buckets mapping. If a task does not have a task specific clamp value it does not refcount any bucket. The moment we assign a task specific clamp value, we need to refcount the task in the bucket corresponding to that clamp value. This will keep the bucket in use at least as long as the task will need that clamp value. -- #include Patrick Bellasi