Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751249AbdH2Egt (ORCPT ); Tue, 29 Aug 2017 00:36:49 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54590 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbdH2Egr (ORCPT ); Tue, 29 Aug 2017 00:36:47 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A202760738 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=pkondeti@codeaurora.org MIME-Version: 1.0 In-Reply-To: <20170825102008.4626-2-patrick.bellasi@arm.com> References: <20170825102008.4626-1-patrick.bellasi@arm.com> <20170825102008.4626-2-patrick.bellasi@arm.com> From: Pavan Kondeti Date: Tue, 29 Aug 2017 10:06:44 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/3] sched/fair: add util_est on top of PELT To: Patrick Bellasi Cc: LKML , linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Paul Turner , Vincent Guittot , John Stultz , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Tim Murray , Todd Kjos , Andres Oportus , Joel Fernandes , Viresh Kumar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1898 Lines: 43 Hi Patrick, On Fri, Aug 25, 2017 at 3:50 PM, Patrick Bellasi wrote: > The util_avg signal computed by PELT is too variable for some use-cases. > For example, a big task waking up after a long sleep period will have its > utilization almost completely decayed. This introduces some latency before > schedutil will be able to pick the best frequency to run a task. > > The same issue can affect task placement. Indeed, since the task > utilization is already decayed at wakeup, when the task is enqueued in a > CPU, this can results in a CPU running a big task as being temporarily > represented as being almost empty. This leads to a race condition where > other tasks can be potentially allocated on a CPU which just started to run > a big task which slept for a relatively long period. > > Moreover, the utilization of a task is, by PELT definition, a continuously > changing metrics. This contributes in making almost instantly outdated some > decisions based on the value of the PELT's utilization. > > For all these reasons, a more stable signal could probably do a better job > of representing the expected/estimated utilization of a SE/RQ. Such a > signal can be easily created on top of PELT by still using it as an > estimator which produces values to be aggregated once meaningful events > happens. > > This patch adds a simple implementation of util_est, a new signal built on > top of PELT's util_avg where: > > util_est(se) = max(se::util_avg, f(se::util_avg@dequeue_times)) > I don't see any wrapper function in this patch that implements this signal. You want to use this signal in the task placement path as a replacement of task_util(), right? Thanks, Pavan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project