Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3780196imm; Mon, 4 Jun 2018 09:06:54 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLW8tgf3gGcTCMT7hrqTBbtodvUQDpQIEtOXGEBJLMs6IVCWIGeLvQeXYttF4YC0eAuRmhc X-Received: by 2002:a65:4e8b:: with SMTP id b11-v6mr3503216pgs.71.1528128414843; Mon, 04 Jun 2018 09:06:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528128414; cv=none; d=google.com; s=arc-20160816; b=OBHmc2k4RnaCO5ESRhZpAd1fCq2a14GN9y5i/koFz4Yqg7mO5qP+8bFIq7Myigr91p 8jn1v0S1rQI3zT/4RLCc4zdhADSePQHD+R2bsaiTk7SIbrWEpavUNllC8b7rlHd+/Pap bcFe4mQ56U2IknORRTyWh7my60JBWx9/O15bHW3ZqhcYbV+3L+zplSBqU7idtY64JWoO o9GTTCdRnPxTZTKMs875AkHSmJnkT8Q7I/jpNfiKKZ9RFBX4gW9PXQ5lp1oi4lm9ODjU evVm4WbIM+lM0mpnOS3SPx21+g/Q9vz8k9qkdUqjZko7j5XOBDcSO9BkfWWVgVBjGpJV MNgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=pXbUZ7i+Cvc1bufWDg9DUMwvNdaJNqIbyD9qENcDF5I=; b=hlYgh1KJ1AJ6yusRIbAMR2WbJWHHI9Y9ZWqVW0lDJoOBZhMgVu9zAlSuB2exEYdqFE JGG203cWvNlGT4w6MYiL3km3MaiGRgegrQOaWMaCbdYh8QBJz2Mzvi8VQrUEJTBzkqLB 7Wj2EfFec71f0WibCpXUj5pcp79sL8BA7L2nsk+WkeaZu+spdKnY8FmHMPrNhFii9XZ6 TuxdvazeqB5KbbRDMGI/+KhOjRK4Oa4dpMSwkzm1WeXPKn9WH2K0C9f59hDjZFtZPoTN YHweaWHaswbSkQX/LG1jyGKxVBLs26Ac1i7Vx73043UMW/9dlsvZf4ZRnOigf8bw5N3x lYWw== 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 m3-v6si12116519plb.27.2018.06.04.09.06.40; Mon, 04 Jun 2018 09:06:54 -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 S1751328AbeFDQGM (ORCPT + 99 others); Mon, 4 Jun 2018 12:06:12 -0400 Received: from foss.arm.com ([217.140.101.70]:45356 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751058AbeFDQGK (ORCPT ); Mon, 4 Jun 2018 12:06:10 -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 2DCF01596; Mon, 4 Jun 2018 09:06:10 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id ED90D3F557; Mon, 4 Jun 2018 09:06:07 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Joel Fernandes , Steve Muckle Subject: [PATCH 0/2] Improve estimated utilization of preempted FAIR tasks Date: Mon, 4 Jun 2018 17:05:58 +0100 Message-Id: <20180604160600.22052-1-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.15.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Here is a small series to improve the estimated utilization of fair tasks which are preempted by either another FAIR task of by tasks of an higher priority scheduling class (i.e. RT and DL). It can certainly be improved, but it has been already functionally tested and given the discussion going on on IRC and in this other thread: https://lkml.org/lkml/2018/5/25/410 1527253951-22709-1-git-send-email-vincent.guittot@linaro.org I wanted to anticipate a possible simple alternative/additional approach to improve CPU utilization tracking for CFS tasks. Thus, every comment and suggestion is more then welcome! The main reasons and the overall idea is explained by the second patch of this series. While the first patch is just a first step in the direction of having a more memory and run-time efficient implementation. The ultimate benefit of this series is to make the CFS class more robust in terms of its integration with the schedutil governor. Indeed, by better estimating the CPU bandwidth requirements for CFS tasks we can assert more accurately their bandwidth demands and be less sensitive to side effect, on PELT, generated by higher priority classes preempting CFS tasks, like the CFS util_avg decay. Cheers Patrick Patrick Bellasi (2): sched/fair: pelt: use u32 for util_avg sched/fair: util_est: add running_sum tracking include/linux/sched.h | 3 ++- kernel/sched/debug.c | 2 +- kernel/sched/fair.c | 33 ++++++++++++++++++++++++--------- 3 files changed, 27 insertions(+), 11 deletions(-) -- 2.15.1