Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp378349ybc; Tue, 19 Nov 2019 02:56:04 -0800 (PST) X-Google-Smtp-Source: APXvYqwEyQg719nDMIfnhZ3AZ6SnK0hEs4LIZDcQmRjM0QUdajk4zrnkQ76V2yuTXQ8M9CkZoDq5 X-Received: by 2002:a5d:474c:: with SMTP id o12mr2249306wrs.170.1574160964685; Tue, 19 Nov 2019 02:56:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574160964; cv=none; d=google.com; s=arc-20160816; b=bfP4UJP8U9Cg+EEm6Rf+zluSzCICTDdRhpwM3kJIsxrjcmZzzG9msC3/qnu0DfsYzh ZINWDimNXb8NL2yo1jVR8sjIrKQIlgvfgF1T6v1z25iNZMncebpC4gRIqZIA13M8/Xtp nKtQ1Uy9EGCpSawSjxilib12mXgkMyI6UP4wCldkQIp0Zy2JOvDNITKqhBBApPdXahvN A7ReI2LWhFXbs2casg7RECpu7aqqWbOzYmQMBwxPkYDQHxFAKKQfPfq47zuivObJRNql sAsTUUxCVmZd+op+gE8ASNkvoP3siPla2OlKzGq+LaoeR4ACfGNK7K+fK3kmj/Lyfttj HZHA== 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 :in-reply-to:references:mime-version:dkim-signature; bh=qqVCqWV0gq/yuZPLqViM0uPHvIcCGNlGcIEn07A4a8s=; b=FbleEd0t7nZwUBDvBJK5E7jqm/H+BA03NKwYqNsusbxm36zUa9tawB+KR/ECog9otd Tr+Gi8r0eLUzCyuJdQ3qqRY7bFrLACDSa/eI3gUwHRSJtnnDdQTNrVtpYqzv9qDAxyq8 0Qetf//f1tf0iwpgmDMvNeNy6OE8BqQQiyCYKe9vBUMWXQtp5K5KfkYzV1NMr+7NMEMX kWaecNB//XjghSuT6lvviDAnI5my1eAMp/J216MtpmpSuWxVlMDnr8hq0S8wa5eIUUOO bcObMK0F9YE5JKHOO8mS8MadRgBtzepJzJ8SVYph2f2Oe0boG4hGbKP3u5lw+QtaukiG QchQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@verdurent-com.20150623.gappssmtp.com header.s=20150623 header.b=TReeyc+4; 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 v35si15101570edm.213.2019.11.19.02.55.39; Tue, 19 Nov 2019 02:56:04 -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; dkim=pass header.i=@verdurent-com.20150623.gappssmtp.com header.s=20150623 header.b=TReeyc+4; 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 S1727698AbfKSKvh (ORCPT + 99 others); Tue, 19 Nov 2019 05:51:37 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:40321 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727504AbfKSKvg (ORCPT ); Tue, 19 Nov 2019 05:51:36 -0500 Received: by mail-vs1-f66.google.com with SMTP id m9so13875675vsq.7 for ; Tue, 19 Nov 2019 02:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verdurent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqVCqWV0gq/yuZPLqViM0uPHvIcCGNlGcIEn07A4a8s=; b=TReeyc+4LNVp7Jbhwu2GXSLf8PLCrM3e2j9URpSqZT4z/2ND/KzmF5Gzx4IBrCY6di 9otq56lE8QnRHWusOWx7JdYBHfXw14BHmiiTDryhXwS1wFBV5tQQLMYj/BkBXuvbd0PB 89KI9PGYcK11qdropyRc3irJZsp5upaeb3de8X8QBc9MAy4FqPYEoRlgd8qQJYsM0U3+ fqDvIkuZkukReyQRlD5ppfm0gToviMnRMpqQtX1o9/oxEW28wakCX+jliIqjDqXQ7+jA 5YkKblYLclv6RqMHbyJAw0ALhPgNuCfKA5mLdagabVG+JTYskcC8a+H13BC1SSZk16oW eHVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqVCqWV0gq/yuZPLqViM0uPHvIcCGNlGcIEn07A4a8s=; b=p+qtJaeeHVZkEPIaq4ndRVbd1k4tkdrmkW6p7dGSbSLCC2hYSys7Tg+Zlyt2jYxf7J VW5P4B7CX6evQy5nQDxDx8ZfRKb4AO33SJkYOg1+5tHv24eDje/HxBXtM+1WuqWUbimP I84UCNhdn1tmUJOhyqxWqWc4PQORuxIqTfUT8VJq3/vowsRqa88kw1SGXTbeeH05buTX 5o68PWeWlbeIJmGq0WH50jIZU/vswdwHsfqkFjIYfImHMnw37I0c+agGjF25GJJ/CjUp wLXJ+iEZ4f4icLejlswQ86WbcUuUCbeDocKWPHdfx7rNxm53CFuXRf1NQN0+9kbqHTFv 1ldQ== X-Gm-Message-State: APjAAAWJNZ8t6FyQ3a3bV5RtKnCemtJ1o4Ic9ZkBOlwC9VQZyejayIyK Ra6c08JCEVKHJipcwDKPkOUeIU/f1l1sNNNJdnK47A== X-Received: by 2002:a67:fb0a:: with SMTP id d10mr21608087vsr.27.1574160693728; Tue, 19 Nov 2019 02:51:33 -0800 (PST) MIME-Version: 1.0 References: <1572979786-20361-1-git-send-email-thara.gopinath@linaro.org> <1572979786-20361-3-git-send-email-thara.gopinath@linaro.org> In-Reply-To: <1572979786-20361-3-git-send-email-thara.gopinath@linaro.org> From: Amit Kucheria Date: Tue, 19 Nov 2019 16:21:22 +0530 Message-ID: Subject: Re: [Patch v5 2/6] sched/fair: Add infrastructure to store and update instantaneous thermal pressure To: Thara Gopinath Cc: Ingo Molnar , Peter Zijlstra , ionela.voinescu@arm.com, Vincent Guittot , Zhang Rui , Eduardo Valentin , qperret@google.com, LKML , Amit Daniel Kachhap , Javi Merino , Daniel Lezcano 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 On Wed, Nov 6, 2019 at 12:20 AM Thara Gopinath wrote: > > Add interface APIs to initialize, update/average, track, accumulate > and decay thermal pressure per cpu basis. A per cpu variable *on a* per cpu basis. > thermal_pressure is introduced to keep track of instantaneous per > cpu thermal pressure. Thermal pressure is the delta between maximum > capacity and capped capacity due to a thermal event. > API trigger_thermal_pressure_average is called for periodic accumulate s/accumulate/accumulation > and decay of the thermal pressure.This API passes on the instantaneous > thermal pressure of a cpu to update_thermal_load_avg to do the necessary > accumulate, decay and average. s/accumulate/accumulation Add blank line here. > API update_thermal_pressure is for the system to update the thermal > pressure by providing a capped maximum capacity. This is redundant given the below sentence. > Considering, trigger_thermal_pressure_average reads thermal_pressure and Lose the comma. > update_thermal_pressure writes into thermal_pressure, one can argue for > some sort of locking mechanism to avoid a stale value. > But considering trigger_thermal_pressure_average can be called from a > system critical path like scheduler tick function, a locking mechanism > is not ideal. This means that it is possible the thermal_pressure value > used to calculate average thermal pressure for a cpu can be > stale for upto 1 tick period. Please consider reflowing all your patch descriptions to make the paragraphs better aligned and easier to read. Leave a blank line between paragraphs. In vim, you can do :gqap at each paragraph. > Signed-off-by: Thara Gopinath > --- > > v3->v4: > - Dropped per cpu max_capacity_info struct and instead added a per > delta_capacity variable to store the delta between maximum > capacity and capped capacity. The delta is now calculated when > thermal pressure is updated and not every tick. > - Dropped populate_max_capacity_info api as only per cpu delta > capacity is stored. > - Renamed update_periodic_maxcap to > trigger_thermal_pressure_average and update_maxcap_capacity to > update_thermal_pressure. > v4->v5: > - As per Peter's review comments folded thermal.c into fair.c. > - As per Ionela's review comments revamped update_thermal_pressure > to take maximum available capacity as input instead of maximum > capped frequency ration. > > --- > include/linux/sched.h | 9 +++++++++ > kernel/sched/fair.c | 37 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 46 insertions(+) > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 263cf08..3c31084 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -1993,6 +1993,15 @@ static inline void rseq_syscall(struct pt_regs *regs) > > #endif > > +#ifdef CONFIG_SMP > +void update_thermal_pressure(int cpu, unsigned long capped_capacity); > +#else > +static inline void > +update_thermal_pressure(int cpu, unsigned long capped_capacity) > +{ > +} > +#endif > + > const struct sched_avg *sched_trace_cfs_rq_avg(struct cfs_rq *cfs_rq); > char *sched_trace_cfs_rq_path(struct cfs_rq *cfs_rq, char *str, int len); > int sched_trace_cfs_rq_cpu(struct cfs_rq *cfs_rq); > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 682a754..2e907cc 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -86,6 +86,12 @@ static unsigned int normalized_sysctl_sched_wakeup_granularity = 1000000UL; > > const_debug unsigned int sysctl_sched_migration_cost = 500000UL; > > +/* > + * Per-cpu instantaneous delta between maximum capacity > + * and maximum available capacity due to thermal events. > + */ > +static DEFINE_PER_CPU(unsigned long, thermal_pressure); > + > #ifdef CONFIG_SMP > /* > * For asym packing, by default the lower numbered CPU has higher priority. > @@ -10401,6 +10407,37 @@ static unsigned int get_rr_interval_fair(struct rq *rq, struct task_struct *task > return rr_interval; > } > > +#ifdef CONFIG_SMP > +/** > + * update_thermal_pressure: Update thermal pressure > + * @cpu: the cpu for which thermal pressure is to be updated for > + * @capped_capacity: maximum capacity of the cpu after the capping > + * due to thermal event. > + * > + * Delta between the arch_scale_cpu_capacity and capped max capacity is > + * stored in per cpu thermal_pressure variable. > + */ > +void update_thermal_pressure(int cpu, unsigned long capped_capacity) > +{ > + unsigned long delta; > + > + delta = arch_scale_cpu_capacity(cpu) - capped_capacity; > + per_cpu(thermal_pressure, cpu) = delta; Any reason you to save to delta first and then to the per-cpu variable? Just make it per_cpu(thermal_pressure, cpu) = arch_scale_cpu_capacity(cpu) - capped_capacity; > +} > +#endif > + > +/** > + * trigger_thermal_pressure_average: Trigger the thermal pressure accumulate > + * and average algorithm > + */ > +static void trigger_thermal_pressure_average(struct rq *rq) > +{ > +#ifdef CONFIG_SMP > + update_thermal_load_avg(rq_clock_task(rq), rq, > + per_cpu(thermal_pressure, cpu_of(rq))); > +#endif > +} > + > /* > * All the scheduling class methods: > */ > -- > 2.1.4 >