From patchwork Wed May 24 05:29:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 100410 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp115318qge; Tue, 23 May 2017 22:30:42 -0700 (PDT) X-Received: by 10.84.193.129 with SMTP id f1mr41346351pld.129.1495603842701; Tue, 23 May 2017 22:30:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495603842; cv=none; d=google.com; s=arc-20160816; b=C96v4gHFkwKoBUGUTNDvLQe/qmdvALzaNh16ENAMulOapCYZ9Kw3QJndjq8m31GLvb pSD/1wp/61IE0uzENXm/SL+bri+vF8rpmPS88crg/U73w/RSS1W4SfJpj13LyohMQ4Qt a4IhKpbloMi1ENhtTZfmB7wipJunJlSi+nMzLCnS6A5iNuf0dlNuhbvpcM9I2+sXjfeO CzVyNeEao0X6Ql7MR9fBOrEricdmGuSb6lNwHn/VcB9Y7uayohk1EUtuIx07RuGxMpwX 5UNlf4bpWnIfrTfO1h5yyIwHG3oiiHqV5SabUYAv/LlyylosEqY68WEuJD0uEQCR0NNP vtxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=SP/q4iQ4btUb814MlQmjzAY9hWDI90Ii7812LgNytC0=; b=fkvxHR2muS8mN7u9LbbK+DJJ7UFVObxdoAuq4rSjK8Z8fzKTqNu1QJmFPHhRXlnA8n ahqODmSnl+ry3fHs2B3vbYJlAIM/2cUcxI/L9EzTdD5wMxLvGIOGnxWn5s5mNN/np9OK mJTC6BbudSVvj50EhxAGfLygXQBGsimeRGf4Sk/UlNrucES7Jz3Z5lFFf4gRwrt5JVds RSL5ceYJ4EX2s+pfDK7HlSptNs1DhL5tPfkKpC5DvHrAA3O28ienAGyxZizXH5cHvsZW 2wZ63b/hro/C6pstt+s5xlVjzIezTXelz90V2YA/q1/HihRnw/Z4iamQB96uZv51b3L+ IxUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k20si12451096pfb.241.2017.05.23.22.30.42; Tue, 23 May 2017 22:30:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966145AbdEXFa3 (ORCPT + 6 others); Wed, 24 May 2017 01:30:29 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:35471 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966141AbdEXFaZ (ORCPT ); Wed, 24 May 2017 01:30:25 -0400 Received: by mail-pg0-f52.google.com with SMTP id q125so60140837pgq.2 for ; Tue, 23 May 2017 22:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=SP/q4iQ4btUb814MlQmjzAY9hWDI90Ii7812LgNytC0=; b=HxROPyMuV/0r++Eao6WIAdIbaN+kzGqzbt70FvfmzfJ85/COMVPMQQN0Gxg7UYkjW/ WyCW/NwjsYcfAKa1ZooSIink4nL3vNipSsFT7/Z+tVw7EyhGHUQGgQp3xf8jHbc4333p YvEg8luNU86ObJvNpxFp91rHzIzYhCTBrjUbU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=SP/q4iQ4btUb814MlQmjzAY9hWDI90Ii7812LgNytC0=; b=GK4SC7NzDUfOWEhWDPl7pVRZ5QW49hazgsIKyVqZCkp+5f6sokalV58kpoy6MLD47s mRRLAEgQazRZZ4i/c5jsgS7n7ojPzWYbzMeTgyqK/6S/MPV+ZvAt/Jikak+4NmH7cSje IWukn4NVqxH1C/mV1YN2oTqjvEp8bypCWUhUtYODMP+GBtcEe1ISVYKiJQqTDC93aDl4 /4edxFHpeejiPDLgWx/B7JVwFpp6nEyK6t9GQGsE4YWixYIRsjORAoO5s+Wi6RsU2Fdc DUyNFSRFDyb5oFDlmTiMh25upWiV8TxLHDBEZxR1oOkkI0rAqmSFIdfQud9MaWkmaCUf FfuA== X-Gm-Message-State: AODbwcDwhQ2KpKoIxwiXyVzEwWAAS+Td2gxhbDZZ182xvRK/sMUAmn0A 5Gq3Z7j67wBiB5q1Lsie6Q== X-Received: by 10.99.36.199 with SMTP id k190mr35552939pgk.83.1495603824262; Tue, 23 May 2017 22:30:24 -0700 (PDT) Received: from localhost ([122.167.143.58]) by smtp.gmail.com with ESMTPSA id y20sm3820564pfb.93.2017.05.23.22.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 22:30:23 -0700 (PDT) From: Viresh Kumar To: Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, Vincent Guittot , "4 . 6+" Subject: [PATCH 1/6] sched: fair: Call cpufreq update util handlers less frequently on UP Date: Wed, 24 May 2017 10:59:52 +0530 Message-Id: <6abf69a2107525885b616a2c1ec03d9c0946171c.1495603536.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.13.0.70.g6367777092d9 In-Reply-To: References: In-Reply-To: References: Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org For SMP systems, update_load_avg() calls the cpufreq update util handlers only for the top level cfs_rq (i.e. rq->cfs). But that is not the case for UP systems. update_load_avg() calls util handler for any cfs_rq for which it is called. This would result in way too many calls from the scheduler to the cpufreq governors when CONFIG_FAIR_GROUP_SCHED is enabled. Reduce the frequency of these calls by copying the behavior from the SMP case, i.e. Only call util handlers for the top level cfs_rq. Fixes: 536bd00cdbb7 ("sched/fair: Fix !CONFIG_SMP kernel cpufreq governor breakage") Signed-off-by: Viresh Kumar --- I wasn't sure if we would like to mark Stable for this or not. Cc: 4.6+ # 4.6+ --- kernel/sched/fair.c | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) -- 2.13.0.70.g6367777092d9 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 47a0c552c77b..a0a97497c400 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2728,6 +2728,29 @@ static inline void update_cfs_shares(struct sched_entity *se) } #endif /* CONFIG_FAIR_GROUP_SCHED */ +static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) +{ + if (&this_rq()->cfs == cfs_rq) { + /* + * There are a few boundary cases this might miss but it should + * get called often enough that that should (hopefully) not be + * a real problem -- added to that it only calls on the local + * CPU, so if we enqueue remotely we'll miss an update, but + * the next tick/schedule should update. + * + * It will not get called when we go idle, because the idle + * thread is a different class (!fair), nor will the utilization + * number include things like RT tasks. + * + * As is, the util number is not freq-invariant (we'd have to + * implement arch_scale_freq_capacity() for that). + * + * See cpu_util(). + */ + cpufreq_update_util(rq_of(cfs_rq), 0); + } +} + #ifdef CONFIG_SMP /* * Approximate: @@ -3215,29 +3238,6 @@ static inline void set_tg_cfs_propagate(struct cfs_rq *cfs_rq) {} #endif /* CONFIG_FAIR_GROUP_SCHED */ -static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) -{ - if (&this_rq()->cfs == cfs_rq) { - /* - * There are a few boundary cases this might miss but it should - * get called often enough that that should (hopefully) not be - * a real problem -- added to that it only calls on the local - * CPU, so if we enqueue remotely we'll miss an update, but - * the next tick/schedule should update. - * - * It will not get called when we go idle, because the idle - * thread is a different class (!fair), nor will the utilization - * number include things like RT tasks. - * - * As is, the util number is not freq-invariant (we'd have to - * implement arch_scale_freq_capacity() for that). - * - * See cpu_util(). - */ - cpufreq_update_util(rq_of(cfs_rq), 0); - } -} - /* * Unsigned subtract and clamp on underflow. * @@ -3483,7 +3483,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq) static inline void update_load_avg(struct sched_entity *se, int not_used1) { - cpufreq_update_util(rq_of(cfs_rq_of(se)), 0); + cfs_rq_util_change(cfs_rq_of(se)); } static inline void