From patchwork Mon May 22 11:17:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 9739945 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 5C1166034C for ; Mon, 22 May 2017 11:17:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4504E286E0 for ; Mon, 22 May 2017 11:17:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 37AC4286FE; Mon, 22 May 2017 11:17:52 +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 9BBFA286E0 for ; Mon, 22 May 2017 11:17:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756829AbdEVLRu (ORCPT ); Mon, 22 May 2017 07:17:50 -0400 Received: from mail-pf0-f181.google.com ([209.85.192.181]:35110 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752927AbdEVLRt (ORCPT ); Mon, 22 May 2017 07:17:49 -0400 Received: by mail-pf0-f181.google.com with SMTP id n23so79416469pfb.2 for ; Mon, 22 May 2017 04:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=E3LdIE4qx64UkNkXB58HGhHZW1AwSD7d3n2ZnWpdTXg=; b=fbFOcvvESInQ/Djx+uIlSDFPDD/4iW3mkJEfinyxxTPOBz5nhMEVF0wbDulV8oNcjE 0xWk/hrJEd0rSt7fRqqjTmutqviCVWCkpYYARAXkIUrR9Ku3QsIKrnfuwWXDi0Fx5IXH oAZNPoPmLEyLo5grNnwKcaaul37cMKcabGRb0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=E3LdIE4qx64UkNkXB58HGhHZW1AwSD7d3n2ZnWpdTXg=; b=QeAJz4DnA270WrH+BuqIVJHC1nK3h1upy2A7PJcrEGqnJk/1fRSQxMaeTDadHJIpZ5 70//mC4RfGJfWRGiwzpb266bLaWqztxTMCzQlgDqkd20iQO2BFAtLrc6oZJjP3o4kzws 9MVoX/E5DD0Vj2/eChn3EHFFtkoMfx9QRU6gtElVBxRW0H7rbWO3IAy89ZYqEV6ILB6R vmXfGpMOER3FEsYwxvK5os+RRoC8/XULAG15A51rWrc5r0rf4fF4ba0fpXqYcN2JPMhQ yPz5ylrJxRg0BoY5h5lCettYdMktqWU5VF80mdkITsB0fdYILHT07VPPqYYwAX8dceLu GfWg== X-Gm-Message-State: AODbwcBkl8Fl1+i2jeCG4rMhkJd1a4t+nwQeTRkw/znslMuSyQoTMagb boP9BsHqFBd/yH7j X-Received: by 10.98.93.217 with SMTP id n86mr25142600pfj.113.1495451868698; Mon, 22 May 2017 04:17:48 -0700 (PDT) Received: from leoy-ThinkPad-T440 (li1068-205.members.linode.com. [106.184.3.205]) by smtp.gmail.com with ESMTPSA id u9sm28831967pgn.55.2017.05.22.04.17.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 22 May 2017 04:17:46 -0700 (PDT) Date: Mon, 22 May 2017 19:17:38 +0800 From: Leo Yan To: Viresh Kumar Cc: Brendan Jackman , linaro-kernel@lists.linaro.org, Rafael Wysocki , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Amit Kucheria Subject: Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns Message-ID: <20170522111738.GB9325@leoy-ThinkPad-T440> References: <16157eb75bb26cca73a0da930e49f2549b96fd65.1495429745.git.viresh.kumar@linaro.org> <87h90d2mqm.fsf@arm.com> <20170522105522.GG6510@vireshk-i7> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170522105522.GG6510@vireshk-i7> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Mon, May 22, 2017 at 04:25:22PM +0530, Viresh Kumar wrote: > On 22-05-17, 11:45, Brendan Jackman wrote: > > Hi Viresh, > > > > On Mon, May 22 2017 at 05:10, Viresh Kumar wrote: > > > The rate_limit_us for the schedutil governor is getting set to 500 ms by > > > default for the ARM64 hikey board. And its way too much, even for the > > > default value. Lets set the default transition_delay_ns to something > > > more realistic (10 ms), while the userspace always have a chance to set > > > something it wants. > > > > Just a thought - do you think we can treat the reported transition > > latency as a proxy for the "cost" of freq transitions? I.e. assume that > > on platforms with very fast frequency switching it's probably cheap to > > switch frequency and we want schedutil to respond quickly, whereas on > > platforms with big latencies, frequency switches might be expensive and > > we probably want hysteresis. > > > > If that makes sense then maybe we could use 10 * transition_latency / > > NSEC_PER_USEC, when transition_latency is reported? Otherwise 10ms seems > > sensible to me.. > > So my platform (hikey) does provide transition-latency as 500 us. But > schedutil multiplies that with LATENCY_MULTIPLIER (1000) and that > makes it 500000 rate_limit_us, which is unacceptable. > > @Rafael: Why does the LATENCY_MULTIPLIER has such a high value? I am > not sure I understood completely on why we have this multiplier :( This afternoon Amit pointed me for this patch, should fix as below? Otherwise it seems directly assign the same value from unit 'ns' to 'us' but without any value conversion. Thanks, Leo Yan diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 76877a6..dcc90fc 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -538,7 +538,7 @@ static int sugov_init(struct cpufreq_policy *policy) unsigned int lat; tunables->rate_limit_us = LATENCY_MULTIPLIER; - lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC; + lat = policy->cpuinfo.transition_latency / NSEC_PER_MSEC; if (lat) tunables->rate_limit_us *= lat; }