Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3475657imm; Fri, 20 Jul 2018 18:25:34 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfacPhZ+n1bbtAXsfAvP4Bwp6hZWDn5iU09/ZpdLwKVhztsg12Po7qMxfNboD9yD5eX+YvF X-Received: by 2002:a62:d1b:: with SMTP id v27-v6mr4369913pfi.87.1532136334499; Fri, 20 Jul 2018 18:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532136334; cv=none; d=google.com; s=arc-20160816; b=wBnUX8dkoKxOrc40OGNvyFR2E352OJKoihu4tOSlP33YL7Y6WiAf8DwZmwzVKUL4uE edTAuD9o2J6v1w0to43UVqKpCiRj+QKocnqbJrRSlOs7BIj6Ql/7jLFnFtWN5gUPNQj0 hjnJFZkB8J7sYmTew1yJRFZjDojOgOZ3sduv5x2K+E+NQMyXfCOhGQ9O+rCM1mZrcpgN /DE9JuyMnMUW9oGD7Nlx86NtSkalvgXLRIGKhsxwK7nIO+9fXHUJJ5VSW3BuLh3Ht/qj 5uaPmQa2tWlnPR0fCAE6OUlc/cwZOQ49Zdvf7hv9Ag5qLS5pRmmUHlkM+QabFe5FEiNv /0tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=3BZcRJeWvcBCYQmfS3G3Oh+DroCNUxj7KQd1G2vJRXU=; b=kkmnJGt6s5iA4QdyZXtgoYV+OL7feVB2OHTUFZke50hygDY7zJGbI/OS1uLqTX8fMS /9RutDiI8wdJVDt9UUtTHt4/zZI8QUp2YBHGQ6wvUphCsGZRiwDaR+EMKMbVZKPS1v8U XiIXWIqBgs2u7Xay6aw+NB/jxaEBZwj/BKNItvSoNnhF7M4fjV27TWOkE74zZACqSRJ6 JX9bRPIfVPf266kBuIcLl1EkSwZjnyNRiD9ZsR8pjhTOzG9zDvl7VfXyxaFTu3ngbx9r 9O9xHd0CCtr4V7JJF8H4vszV410NT0cfJ8i1JLbgUUpSFy5tzO/j7x9+VeUsNkcAG8Vh SGCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=J6ThI6qp; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13-v6si3078772pgc.409.2018.07.20.18.25.19; Fri, 20 Jul 2018 18:25:34 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=J6ThI6qp; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727545AbeGUCOq (ORCPT + 99 others); Fri, 20 Jul 2018 22:14:46 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:41654 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727304AbeGUCOq (ORCPT ); Fri, 20 Jul 2018 22:14:46 -0400 Received: by mail-io0-f193.google.com with SMTP id q9-v6so11319113ioj.8 for ; Fri, 20 Jul 2018 18:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3BZcRJeWvcBCYQmfS3G3Oh+DroCNUxj7KQd1G2vJRXU=; b=J6ThI6qp7l52p25RzwDFlyFMnBPs4z44TxZoDuT4G4+RTbTLGW+hgdFxLbVlPFZwBc OAMur4t+DSDOKGjpGs83JOIHsblBkuyGwir5V/OnPgW1L1kITAziJw5cswrU4p68rq3B YOWwXanUA0McApZqgHfd+FJ4NUwMUuz4eGsrxkLXjfjwdpqEzeK93PsVOrOdfpyKIYjK 6Av66oUgkquAY0P7n5QSFpxSU0e3SvNg0NOZK6+RFMaaIWq4aq0nzObirADye0ouKxcs Y0rO9E9Lwldpenl759ag2unyxY1Lr9F86ls3PscP89+EE9XC+2/gJz+IzK8Bs+n6/m6V 9RGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3BZcRJeWvcBCYQmfS3G3Oh+DroCNUxj7KQd1G2vJRXU=; b=IOFbz4XfZLgGfDV/ZCqy6GpnW0AN4BuA7Q0vRDrpzW98E3aYn6wINYzTxAGwkWsTDS NLXx7DmQ6568ByFaDkBIRrwn4++PjDV8NMeWWOtMgrjFb3wB+MzfVEf3GxjkrR5RR0Z5 25PpHIhE/2Tyi9Yq73K2ToarZyCA2zmsFaB22uFBMN1D2e3q1uzaGUWkTk8GfgIoIv90 kvH83VKGsSTf9Qa0IuM9VMrgn8lDRnUpRZTpE63EkhRIPu99ThFswI+tRRCdSXC0klIN MQOofcu6F6BWJZ0TKzkVoHwRvwFksF0wH89XUiQqQKmT2mcK9Ps6B9TAUNphxruCRDKo C74w== X-Gm-Message-State: AOUpUlEXWgyRwngCm9cV5n3rBONDvSoXy61VXD8V0eTtLMqdhCRwS6e5 +Xx/T6fwgbgmj9o7soSKaLqG3FS7aXVnlbN4x2gdeQ== X-Received: by 2002:a6b:87db:: with SMTP id r88-v6mr3585077ioi.243.1532136237738; Fri, 20 Jul 2018 18:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:e445:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 18:23:57 -0700 (PDT) In-Reply-To: <20180716082906.6061-8-patrick.bellasi@arm.com> References: <20180716082906.6061-1-patrick.bellasi@arm.com> <20180716082906.6061-8-patrick.bellasi@arm.com> From: Suren Baghdasaryan Date: Fri, 20 Jul 2018 18:23:57 -0700 Message-ID: Subject: Re: [PATCH v2 07/12] sched/core: uclamp: enforce last task UCLAMP_MAX To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Patrick, On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi wrote: > When a util_max clamped task sleeps, its clamp constraints are removed > from the CPU. However, the blocked utilization on that CPU can still be > higher than the max clamp value enforced while that task was running. > This max clamp removal when a CPU is going to be idle could thus allow > unwanted CPU frequency increases, right while the task is not running. > > This can happen, for example, where there is another (smaller) task > running on a different CPU of the same frequency domain. > In this case, when we aggregates the utilization of all the CPUs in a typo: we aggregate > shared frequency domain, schedutil can still see the full non clamped > blocked utilization of all the CPUs and thus eventually increase the > frequency. > > Let's fix this by using: > > uclamp_cpu_put_id(UCLAMP_MAX) > uclamp_cpu_update(last_clamp_value) > > to detect when a CPU has no more RUNNABLE clamped tasks and to flag this > condition. Thus, while a CPU is idle, we can still enforce the last used > clamp value for it. > > To the contrary, we do not track any UCLAMP_MIN since, while a CPU is > idle, we don't want to enforce any minimum frequency > Indeed, we relay just on blocked load decay to smoothly reduce the typo: We rely > frequency. > > Signed-off-by: Patrick Bellasi > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > Cc: Todd Kjos > Cc: Joel Fernandes > Cc: Juri Lelli > Cc: Dietmar Eggemann > Cc: Morten Rasmussen > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > --- > kernel/sched/core.c | 30 ++++++++++++++++++++++++++---- > kernel/sched/sched.h | 2 ++ > 2 files changed, 28 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index b2424eea7990..0cb6e0aa4faa 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -930,7 +930,8 @@ uclamp_group_find(int clamp_id, unsigned int clamp_value) > * For the specified clamp index, this method computes the new CPU utilization > * clamp to use until the next change on the set of RUNNABLE tasks on that CPU. > */ > -static inline void uclamp_cpu_update(struct rq *rq, int clamp_id) > +static inline void uclamp_cpu_update(struct rq *rq, int clamp_id, > + unsigned int last_clamp_value) > { > struct uclamp_group *uc_grp = &rq->uclamp.group[clamp_id][0]; > int max_value = UCLAMP_NONE; > @@ -948,6 +949,19 @@ static inline void uclamp_cpu_update(struct rq *rq, int clamp_id) > if (max_value >= SCHED_CAPACITY_SCALE) > break; > } > + > + /* > + * Just for the UCLAMP_MAX value, in case there are no RUNNABLE > + * task, we keep the CPU clamped to the last task's clamp value. > + * This avoids frequency spikes to MAX when one CPU, with an high > + * blocked utilization, sleeps and another CPU, in the same frequency > + * domain, do not see anymore the clamp on the first CPU. > + */ > + if (clamp_id == UCLAMP_MAX && max_value == UCLAMP_NONE) { > + rq->uclamp.flags |= UCLAMP_FLAG_IDLE; > + max_value = last_clamp_value; > + } > + > rq->uclamp.value[clamp_id] = max_value; > } > > @@ -977,13 +991,21 @@ static inline void uclamp_cpu_get_id(struct task_struct *p, > uc_grp = &rq->uclamp.group[clamp_id][0]; > uc_grp[group_id].tasks += 1; > > + /* Force clamp update on idle exit */ > + uc_cpu = &rq->uclamp; > + clamp_value = p->uclamp[clamp_id].value; > + if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) { The condition below is not needed because UCLAMP_FLAG_IDLE is set only for UCLAMP_MAX clamp_id, therefore the above condition already covers the one below. > + if (clamp_id == UCLAMP_MAX) > + uc_cpu->flags &= ~UCLAMP_FLAG_IDLE; > + uc_cpu->value[clamp_id] = clamp_value; > + return; > + } > + > /* > * If this is the new max utilization clamp value, then we can update > * straight away the CPU clamp value. Otherwise, the current CPU clamp > * value is still valid and we are done. > */ > - uc_cpu = &rq->uclamp; > - clamp_value = p->uclamp[clamp_id].value; > if (uc_cpu->value[clamp_id] < clamp_value) > uc_cpu->value[clamp_id] = clamp_value; > } > @@ -1028,7 +1050,7 @@ static inline void uclamp_cpu_put_id(struct task_struct *p, > uc_cpu = &rq->uclamp; > clamp_value = uc_grp[group_id].value; > if (clamp_value >= uc_cpu->value[clamp_id]) > - uclamp_cpu_update(rq, clamp_id); > + uclamp_cpu_update(rq, clamp_id, clamp_value); > } > > /** > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 1207add36478..7e4f10c507b7 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -783,6 +783,8 @@ struct uclamp_group { > * values, i.e. no min/max clamping at all. > */ > struct uclamp_cpu { > +#define UCLAMP_FLAG_IDLE 0x01 > + int flags; > int value[UCLAMP_CNT]; > struct uclamp_group group[UCLAMP_CNT][CONFIG_UCLAMP_GROUPS_COUNT + 1]; > }; > -- > 2.17.1 >