Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932627AbbLNOC6 (ORCPT ); Mon, 14 Dec 2015 09:02:58 -0500 Received: from mail-lf0-f47.google.com ([209.85.215.47]:34832 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932510AbbLNOCx (ORCPT ); Mon, 14 Dec 2015 09:02:53 -0500 MIME-Version: 1.0 In-Reply-To: <566A7FD2.4050601@unitn.it> References: <1449641971-20827-1-git-send-email-smuckle@linaro.org> <1449641971-20827-10-git-send-email-smuckle@linaro.org> <56697DCB.5050800@unitn.it> <566A7FD2.4050601@unitn.it> From: Vincent Guittot Date: Mon, 14 Dec 2015 15:02:32 +0100 Message-ID: Subject: Re: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity To: Luca Abeni Cc: Steve Muckle , Peter Zijlstra , Ingo Molnar , linux-kernel , "linux-pm@vger.kernel.org" , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette 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: 2831 Lines: 81 On 11 December 2015 at 08:48, Luca Abeni wrote: > Hi Vincent, > > On 12/10/2015 05:11 PM, Vincent Guittot wrote: > [...] >>> >>> If yes, I think your approach is safe (and easier to implement - modulo a >>> small >>> issue when a task terminates of switches to other scheduling policies; I >>> think >>> there already are some "XXX" comments in the current code). However, it >>> allows to >>> save less energy (or reclaim less CPU time). For example, if I create a >>> SCHED_DEADLINE >>> task with runtime 90ms and period 100ms it will not allow to scale the >>> CPU >>> frequency >>> even if it never executes (because is always blocked). >> >> >> Yes, i agree. If the task behavior is not aligned with its deadline >> parameters, we will over provisioned CPU capacity to the deadline >> scheduler. >> This metric is not used to select the OPP but to provisioned some CPU >> capacity to the deadline scheduler and to inform the CFS scheduler of >> the remaining capacity. > > Ah, sorry; I missed this point. > > >>>>> + /* This is the "average utilization" for this runqueue */ >>>>> + s64 avg_bw; >>>>> }; >>> >>> >>> Small nit: why "average" utilization? I think a better name would be >>> "runqueue utilization" >>> or "local utilization", or something similar... If I understand correctly >>> (sorry if I >>> missed something), this is not an average, but the sum of the >>> utilisations >>> of the tasks >>> on this runqueue... No? >> >> >> I have used "average" because it doesn't reflect the active/actual >> utilization of the run-queue but the forecasted average bandwidth of >> the CPU that will be used by deadline task. > > Well, this is just nitpicking, so feel free to ignore (I just mentioned > this point because I was initially confused by the "average" name). But I > think this is "maximum", or "worst-case", not "average", because (as far > as I can understand) this field indicates that SCHED_DEADLINE tasks will > not be able to consume more than this fraction of CPU (if they try to > consume more, the scheduler throttles them). > >> I'm open to change the name if another one makes more sense > > In real-time literature this is often called simply "utilization" (or > "worst-case > utilization" by someone): when a task can have a variable execution time, > its > utilization is defined as WCET (maximum execution time) / period. ok. Let follow real-time literature wording and remove "average" to keep only utilization. so the variable will be named: s64 util_bw; Thanks > > > > Luca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/