Received: by 10.223.185.116 with SMTP id b49csp6062429wrg; Wed, 28 Feb 2018 03:24:16 -0800 (PST) X-Google-Smtp-Source: AH8x226rvXIGfq6XGEh8Fqqyz/2THYmv1TkRt8LDqsA1w7zpOBYup1fGPTl25hA9+OrA+pmaRy4P X-Received: by 10.99.155.1 with SMTP id r1mr14277665pgd.422.1519817056468; Wed, 28 Feb 2018 03:24:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519817056; cv=none; d=google.com; s=arc-20160816; b=Xu2ZEAcJjQI9/wI3c+mOLM12eMgNsP/CtttrmfFodsHf1p7813ujrwWAO/x7Kcdo6A fCuCwMaEaQB947n8txqsXQY0I9pOU4sSjHlrYBMg+r1ufDQoMvfojvR5xA7wAcuWTSMN 5NGb9PN86GHpl5Bb1uNLKHL4a+Xt6RyTKMYPuT6OnmDf2MzXv/gXidbPqLwI0nrGynCG lQR1xolXNV4bPluWIiiLuM4fWRXn3gnc4UhUYLe30QbsLRUh0ztvxSoW8ayxDaYIV1ln 9okGT+6AwxvBQ1jpuhP/IiGXyuiIdo9c6E7uMEVj5rnHPgmCdQXhjKprALSVS4gwFXXP lpjg== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=nuMdnlHSkiI6Qd3Aq03Z1mfKxog3EKm2gdigg1nRkSE=; b=0v0vR4BlVzmZ9aTxfjhIGnZl8sRmhKVtOT0G8VzoRgWBlIFoP+93pHqyLTKzGxtF+M oRvpAWYq7kZeX0tvuYoLm7sEoFNm/a6vDaQz3TD5XggscruuPcYQBDgbhKDH/OWM1Bx/ Lp/2LtY+OeL9Z8e3N3AVJE/M0UOC4z/HC2+wZoI76/++neuaEMU5PpcvjKyOG6rV5aw9 Huv6/t1vGM8uSryfy1l4v3yMx1dTmUGsLNEjA/SjXkPWAZ+eXXcfaOEGLwvk+/iCWTo8 ZpA9bKnhCo1VxG3VVgvL6K4TBoXmpD1G1I4tGHNhij1jj6FSe/pxX/pgwvZjeSje4elH xiRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=jvEQfGKC; 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 e33-v6si1130520pld.493.2018.02.28.03.23.46; Wed, 28 Feb 2018 03:24:16 -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=fail header.i=@gmail.com header.s=20161025 header.b=jvEQfGKC; 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 S1752183AbeB1LWt (ORCPT + 99 others); Wed, 28 Feb 2018 06:22:49 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:44618 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751777AbeB1LWs (ORCPT ); Wed, 28 Feb 2018 06:22:48 -0500 Received: by mail-oi0-f67.google.com with SMTP id b8so1476271oib.11; Wed, 28 Feb 2018 03:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nuMdnlHSkiI6Qd3Aq03Z1mfKxog3EKm2gdigg1nRkSE=; b=jvEQfGKCHvfx3As3Y/O+p0wuc5k7nETgaG2TiZr1uOLoOdcoO/baAVFD0ZsgaILdng EK5PZJmW6+oj1k+nQB8peTcEc10R/yTpgqG6GCZqFjhP5faSzOsWxT4Zs5AkIfKFBWp6 XW/V80HQdkiRiOHcoxEPgFOZfg8hbrcpHgd2IPmy7fE4Q1y2xERwU3e6BaQyOOoCAKqi M5CdgOkXq3gL7polSY3En5Nza7OOXLvbNJXRzUjDUEYATZO4Ys5PplJoSFR8xPyWiuG1 5BSEArWMTnN0GCS6Tz83g0zn1hhdk4wkUHe891msG8zHTyo1ycpS3SKErMPtpv0APzsz Y7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nuMdnlHSkiI6Qd3Aq03Z1mfKxog3EKm2gdigg1nRkSE=; b=Ta0LprBRfwLfJoGEVWmtZ7rlP8lrvCLwib8JJvlI0JhuqbtWQ2WhAjskpqz2Nzc96m BUesEejOycXnWOz/0Add39prqj2DrDUnz9x6p8hNuw3le1l7thysd+y+FoWdvtxDJxnl M6q7Yx2Y6vBI9euu6d/ldurl1qLAR2iX2PCycTqro066l1+uldcKcNJ2bInsF3La0/PT HmvYFQAITRqYWjqwkb4FelCNUqPetAUxhoEjOdSHmKwcs+6zF9kVbfpjBa5RO2sBFzOg Imb3BelhbPZJdU639rBrCEHGYAVYv6v7CSWufGCxs087hnXMfbzeZuQSl7m+Wl1JRWwG Eqog== X-Gm-Message-State: APf1xPDOhM2l25XZxU3WP87XTe5bnEtMx847RrACSiBq2RRa5LAHe39P 4uR3QOV0k1NAoKa6nlIrrTQmWYVNCQYJ/SEyKD0= X-Received: by 10.202.83.73 with SMTP id h70mr10499466oib.154.1519816967313; Wed, 28 Feb 2018 03:22:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.44.146 with HTTP; Wed, 28 Feb 2018 03:22:46 -0800 (PST) In-Reply-To: <1519815970-5686-1-git-send-email-claudio@evidence.eu.com> References: <1519815970-5686-1-git-send-email-claudio@evidence.eu.com> From: "Rafael J. Wysocki" Date: Wed, 28 Feb 2018 12:22:46 +0100 X-Google-Sender-Auth: vDvcry_HlGNhKki_7k8fg9qD-7k Message-ID: Subject: Re: [PATCH v2] cpufreq: schedutil: rate limits for SCHED_DEADLINE To: Claudio Scordino Cc: Peter Zijlstra , "Rafael J . Wysocki" , Ingo Molnar , Patrick Bellasi , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Viresh Kumar , Vincent Guittot , Todd Kjos , Joel Fernandes , Linux PM , Linux Kernel Mailing List 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, Feb 28, 2018 at 12:06 PM, Claudio Scordino wrote: > When the SCHED_DEADLINE scheduling class increases the CPU utilization, > we should not wait for the rate limit, otherwise we may miss some > deadline. > > Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have > shown reductions of even 10% of deadline misses with a negligible > increase of energy consumption (measured through Baylibre Cape). > > Signed-off-by: Claudio Scordino > CC: Ingo Molnar > CC: Patrick Bellasi > CC: Dietmar Eggemann > CC: Morten Rasmussen > CC: Juri Lelli > CC: Viresh Kumar > CC: Vincent Guittot > CC: Todd Kjos > CC: Joel Fernandes > CC: linux-pm@vger.kernel.org > CC: linux-kernel@vger.kernel.org > --- > Changes from v1: > - Logic moved from sugov_should_update_freq() to > sugov_update_single()/_shared() to not duplicate data structures > - Rate limit not ignored in case of "fast switch" I'm not sure about this last bit. IMO you can set sg_policy->need_freq_update even in the "fast switch" case to start with and special case it in the future if that turns out to be problematic. That is, unless you have data indicating that it already is problematic, of course. :-) > --- > kernel/sched/cpufreq_schedutil.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 7936f54..ca6ce72 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -273,6 +273,14 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, > sugov_set_iowait_boost(sg_cpu, time); > sg_cpu->last_update = time; > > + /* > + * Make sugov_should_update_freq() ignore the rate limit when DL > + * has increased the utilization. > + */ > + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && > + !(sg_policy->policy->fast_switch_enabled)) > + sg_policy->need_freq_update = true; > + > if (!sugov_should_update_freq(sg_policy, time)) > return; > > @@ -354,6 +362,14 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, > > raw_spin_lock(&sg_policy->update_lock); > > + /* > + * Make sugov_should_update_freq() ignore the rate limit when DL > + * has increased the utilization. > + */ > + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && > + !(sg_policy->policy->fast_switch_enabled)) > + sg_policy->need_freq_update = true; > + > sugov_get_util(sg_cpu); > sg_cpu->flags = flags; > > -- > 2.7.4 >