From patchwork Fri Dec 15 18:27:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Smythies X-Patchwork-Id: 10115833 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1BA826019C for ; Fri, 15 Dec 2017 18:27:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 147052A0B8 for ; Fri, 15 Dec 2017 18:27:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 075CD2A0BC; Fri, 15 Dec 2017 18:27:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9746E2A0B8 for ; Fri, 15 Dec 2017 18:27:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755534AbdLOS1Q (ORCPT ); Fri, 15 Dec 2017 13:27:16 -0500 Received: from cmta17.telus.net ([209.171.16.90]:40055 "EHLO cmta17.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755409AbdLOS1Q (ORCPT ); Fri, 15 Dec 2017 13:27:16 -0500 Received: from dougxps ([173.180.45.4]) by cmsmtp with SMTP id PuhUenTnq5YhBPuhVe4SEo; Fri, 15 Dec 2017 11:27:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=neo; t=1513362435; bh=IDnllOTu4czHr+yqA+IyzCBWKwHNAC+9XOjEXbj2qlI=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=MlV5EX9BNqrqqcLI+w913JooPz6vGXfEx5Xcct6JdIDvFYx2+79uGVtc35VkbRtQc qDMEgqOjLxzF0h8KxU7T2FhsgxV33wQpPhJqgyTC5Nl6Tp6Gyamo4sCBAk+mI9Fyci Pgy9RqXjjEcMbFht0A8jgcKpVvZqoqhr2i8Ct86omBHFoK3z2xesBgvzVEAIvgOykL q9huNuPhrr0d4Qzm26xa8KBziscV80XXvNAqV3f54Gpn7rFU5Z9ojuLLqRduqSqJqv oweir7t2taaeXUNw5r3t+4nJ2VhJiWHAdYLjZIRL//dvsV7O09klFlxGW9aCRTeRtW bMoN/hTtg9pXw== X-Authority-Analysis: v=2.2 cv=eOz8tDh1 c=1 sm=1 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=kj9zAlcOel0A:10 a=I_0Fh4LRX8ay7Iih0xcA:9 a=CjuIK1q_8ugA:10 From: "Doug Smythies" To: "'Rafael J. Wysocki'" Cc: "'Andy Tang'" , "'Rafael J. Wysocki'" , "'Linux PM'" , "'Viresh Kumar'" , "'Stratos Karafotis'" , "Doug Smythies" References: <20171213061759.GT25177@vireshk-i7> <002001d37577$9706a730$c513f590$@net> PsJoe2WoyTqmMPsJueuzun In-Reply-To: PsJoe2WoyTqmMPsJueuzun Subject: RE: Ask for help on governor Date: Fri, 15 Dec 2017 10:27:12 -0800 Message-ID: <002501d375d2$54f942c0$feebc840$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-ca Thread-Index: AdN1vQeP2fkrL/8fQ7W6K8Wr5RwFcgAEoL9g X-CMAE-Envelope: MS4wfHNOGCxfu+7vdlmnGIx70TPWuqHuYdyXBfB0EYH1hbVNE+0uZBKFpavNaM4Ek7k7VcEc9FQaATcCCklgbAaLE4/0FXJkxvKvqhszebXEKlYF8rnJuhyl GU4UxhWRe8YVFDlpxRpbv7NurL3pvFYDSnTQmHvkfmSB1MRONNMKsvbFCeLsTfcsVUGEWzNr2Y/HrHKnuXZbMP0hGvVroPC36rbW3m/8NbjwJ7esMs9U2jRx o8USWCz4maFfvz0V2jagX0Nfjb57eZk1vDTxUrmFnOen73qZz8AWnPRNBf1djHLx5ueckwDYJpMBhLh0iDiGCU/YxCI5CfKq0QfpX18PMJPBFF8GZXJoI4tD a/fBiqxH Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2017.12.15 07:54 Rafael J. Wysocki wrote: > On Friday, December 15, 2017 8:37:38 AM Doug Smythies wrote: > >> Could you please try the below reversion patch. >> It is on top of kernel 4.15-rc3. >> >> On my system, and for the intel_cpufrequ scaling driver, >> the default sampling_rate goes back to 20000 (which works) >> from 500 uSec (which doesn't), for both the conservative >> and ondemand governors. > > OK > > So AFAICS the problem is that dbs_update() makes assumptions that are not > me, quite obviously, if the sampling interval is less than the tick period. > > For example, the "time_elapsed > 2 * sampling_rate" condition in it may > very well trigger every time in that case and that obviously affects the > conservative governor. It does trigger every time and that is why the conservative gov. sticks at low frequency. > What about the patch below, then? I am testing now, from previous work, and already reported on this thread, I already know that the conservative governor will be O.K.. It will take me awhile to thoroughly test the ondemand governor. At only 1.0 ticks at best it will be quite noisy and more sensitive to work/sleep frequencies for periodic workflows. By the way, I modified your proposed patch, which needed to divide by NSEC_PER_USEC instead of multiply by. i.e. I am testing this: ... Doug diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 58d4f4e..1c2fd1d 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -430,7 +430,14 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) if (ret) goto free_policy_dbs_info; + /* + * The sampling interval should not be greater than the transition + * latency of the CPU, but it also cannot be less than the tick period + * for dbs_update() to work correctly. + */ dbs_data->sampling_rate = cpufreq_policy_transition_delay_us(policy); + if (dbs_data->sampling_rate < TICK_NSEC / NSEC_PER_USEC) + dbs_data->sampling_rate = TICK_NSEC / NSEC_PER_USEC; if (!have_governor_per_policy()) gov->gdbs_data = dbs_data;