From patchwork Mon Jul 25 13:34:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Morten Rasmussen X-Patchwork-Id: 72724 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1151052qga; Mon, 25 Jul 2016 06:36:03 -0700 (PDT) X-Received: by 10.98.56.207 with SMTP id f198mr29480658pfa.83.1469453760948; Mon, 25 Jul 2016 06:36:00 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pb1si33753706pac.1.2016.07.25.06.36.00; Mon, 25 Jul 2016 06:36:00 -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 S1753088AbcGYNft (ORCPT + 29 others); Mon, 25 Jul 2016 09:35:49 -0400 Received: from foss.arm.com ([217.140.101.70]:33759 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752876AbcGYNfS (ORCPT ); Mon, 25 Jul 2016 09:35:18 -0400 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 4BF10BB1; Mon, 25 Jul 2016 06:36:32 -0700 (PDT) Received: from e105550-lin.cambridge.arm.com (e105550-lin.cambridge.arm.com [10.1.211.30]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id D9B573F21A; Mon, 25 Jul 2016 06:35:15 -0700 (PDT) From: Morten Rasmussen To: peterz@infradead.org, mingo@redhat.com Cc: dietmar.eggemann@arm.com, yuyang.du@intel.com, vincent.guittot@linaro.org, mgalbraith@suse.de, sgurrappadi@nvidia.com, freedom.tan@mediatek.com, keita.kobayashi.ym@renesas.com, linux-kernel@vger.kernel.org, Morten Rasmussen Subject: [PATCH v3 10/13] sched/fair: Compute task/cpu utilization at wake-up more correctly Date: Mon, 25 Jul 2016 14:34:27 +0100 Message-Id: <1469453670-2660-11-git-send-email-morten.rasmussen@arm.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1469453670-2660-1-git-send-email-morten.rasmussen@arm.com> References: <1469453670-2660-1-git-send-email-morten.rasmussen@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At task wake-up load-tracking isn't updated until the task is enqueued. The task's own view of its utilization contribution may therefore not be aligned with its contribution to the cfs_rq load-tracking which may have been updated in the meantime. Basically, the task's own utilization hasn't yet accounted for the sleep decay, while the cfs_rq may have (partially). Estimating the cfs_rq utilization in case the task is migrated at wake-up as task_rq(p)->cfs.avg.util_avg - p->se.avg.util_avg is therefore incorrect as the two load-tracking signals aren't time synchronized (different last update). To solve this problem, this patch introduces task_util_wake() which computes the decayed task utilization based on the last update of the previous cpu's last load-tracking update. It is done without having to take the rq lock, similar to how it is done in remove_entity_load_avg(). cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Morten Rasmussen --- kernel/sched/fair.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) -- 1.9.1 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9e217eff3daf..9c6ec3bf75ce 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5377,6 +5377,75 @@ static inline int task_util(struct task_struct *p) return p->se.avg.util_avg; } +/* + * task_util_wake: Returns an updated estimate of the utilization contribution + * of a waking task. At wake-up the task blocked utilization contribution + * (cfs_rq->avg) may have decayed while the utilization tracking of the task + * (se->avg) hasn't yet. + * Note that this estimate isn't perfectly accurate as the 1ms boundaries used + * for updating util_avg in __update_load_avg() are not considered here. This + * results in an error of up to 1ms utilization decay/accumulation which leads + * to an absolute util_avg error margin of 1024*1024/LOAD_AVG_MAX ~= 22 + * (for LOAD_AVG_MAX = 47742). + */ +static inline int task_util_wake(struct task_struct *p) +{ + struct cfs_rq *prev_cfs_rq = &task_rq(p)->cfs; + struct sched_avg *psa = &p->se.avg; + u64 cfs_rq_last_update, p_last_update, delta; + u32 util_decayed; + + p_last_update = psa->last_update_time; + + /* + * Task on rq (exec()) should be load-tracking aligned already. + * New tasks have no history and should use the init value. + */ + if (p->se.on_rq || !p_last_update) + return task_util(p); + + cfs_rq_last_update = cfs_rq_last_update_time(prev_cfs_rq); + delta = cfs_rq_last_update - p_last_update; + + if ((s64)delta <= 0) + return task_util(p); + + delta >>= 20; + + if (!delta) + return task_util(p); + + util_decayed = decay_load((u64)psa->util_sum, delta); + util_decayed /= LOAD_AVG_MAX; + + /* + * psa->util_avg can be slightly out of date as it is only updated + * when a 1ms boundary is crossed. + * See 'decayed' in __update_load_avg() + */ + util_decayed = min_t(unsigned long, util_decayed, task_util(p)); + + return util_decayed; +} + +/* + * cpu_util_wake: Compute cpu utilization with any contributions from + * the waking task p removed. + */ +static int cpu_util_wake(int cpu, struct task_struct *p) +{ + unsigned long util, capacity; + + /* Task has no contribution or is new */ + if (cpu != task_cpu(p) || !p->se.avg.last_update_time) + return cpu_util(cpu); + + capacity = capacity_orig_of(cpu); + util = max_t(long, cpu_rq(cpu)->cfs.avg.util_avg - task_util_wake(p), 0); + + return (util >= capacity) ? capacity : util; +} + static int wake_cap(struct task_struct *p, int cpu, int prev_cpu) { long min_cap, max_cap;