Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753265AbcDURHz (ORCPT ); Thu, 21 Apr 2016 13:07:55 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:34085 "EHLO mail-lf0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751953AbcDURHx (ORCPT ); Thu, 21 Apr 2016 13:07:53 -0400 MIME-Version: 1.0 In-Reply-To: <20160421123341.GJ3408@twins.programming.kicks-ass.net> References: <1460958684-32105-1-git-send-email-wanpeng.li@hotmail.com> <6087716.bi8vDPiZNy@vostro.rjw.lan> <20160420140117.GZ3448@twins.programming.kicks-ass.net> <57180293.1040809@intel.com> <20160421123341.GJ3408@twins.programming.kicks-ass.net> Date: Thu, 21 Apr 2016 19:07:51 +0200 X-Google-Sender-Auth: 6IEy_lo5NFKafnYDikGxmZdL5cs Message-ID: Subject: Re: [PATCH] sched/cpufreq: don't trigger cpufreq update w/o real rt/deadline tasks running From: "Rafael J. Wysocki" To: Peter Zijlstra Cc: Wanpeng Li , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Ingo Molnar , "linux-kernel@vger.kernel.org" , Wanpeng Li , Linux PM list , Steve Muckle 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: 1213 Lines: 33 On Thu, Apr 21, 2016 at 2:33 PM, Peter Zijlstra wrote: > On Thu, Apr 21, 2016 at 09:09:43AM +0800, Wanpeng Li wrote: >> >> Sometimes .update_curr hook is called w/o tasks actually running, it is >> >> captured by: >> >> >> >> u64 delta_exec = rq_clock_task(rq) - curr->se.exec_start; >> >> >> >> We should not trigger cpufreq update in this case for rt/deadline >> >> classes, and this patch fix it. > >> I add a print to print when delta_exec is zero for rt class, something > > So its zero, so what? > >> like below: > >> watchdog/5-48 [005] d... 568.449105: update_curr_rt: rt >> delta_exec is zero >> watchdog/5-48 [005] d... 568.449111: >> => put_prev_task_rt >> => pick_next_task_idle > > So we'll go idle, but as of this point we're still running the rt task. Skipping the update in that case might be the right thing to do, though. It doesn't matter in 4.6-rc, because the current governors don't use util/max anyway, so they just get an extra call they can use to evaluate things. However, it matters for schedutil, because it will (over)react to the special util/max combination then. So this looks like a change to make in 4.7.