Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935015AbcKMTr1 (ORCPT ); Sun, 13 Nov 2016 14:47:27 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:36809 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934249AbcKMTr0 (ORCPT ); Sun, 13 Nov 2016 14:47:26 -0500 X-Greylist: delayed 923 seconds by postgrey-1.27 at vger.kernel.org; Sun, 13 Nov 2016 14:47:26 EST Date: Sun, 13 Nov 2016 11:47:22 -0800 From: Steve Muckle To: "Rafael J. Wysocki" Cc: Saravana Kannan , Viresh Kumar , Rafael Wysocki , Ingo Molnar , Peter Zijlstra , Lists linaro-kernel , Linux PM , Linux Kernel Mailing List , Vincent Guittot , Juri Lelli , Robin Randhawa Subject: Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task Message-ID: <20161113194722.GC29583@graphite.smuckle.net> References: <85bf45982709e06f7f42e1b8f8315945e9d9b6d0.1478858983.git.viresh.kumar@linaro.org> <582670FD.7080203@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1339 Lines: 29 On Sun, Nov 13, 2016 at 03:37:18PM +0100, Rafael J. Wysocki wrote: > > Hold on a sec. I thought during LPC someone (Peter?) made a point that when > > RT thread run, we should bump the frequency to max? So, schedutil is going > > to trigger schedutil to bump up the frequency to max, right? > > No, it isn't, or at least that is unlikely. > > sugov_update_commit() sets sg_policy->work_in_progress before queuing > the IRQ work and it is not cleared until the frequency changes in > sugov_work(). > > OTOH, sugov_should_update_freq() checks sg_policy->work_in_progress > upfront and returns false when it is set, so the governor won't see > its own worker threads run, unless I'm overlooking something highly > non-obvious. FWIW my intention with the original version of this patch (which I neglected to communicate to Viresh) was that it would depend on changing the frequency policy for RT. I had been using rt_avg. It sounds like during LPC there were talks of using another metric. It does appear things would work okay without that but it also seems a bit fragile. There's the window between when the work_in_progress gets cleared and the RT kthread yields. I have not thought through the various scenarios there, what is possible and tested to see if it is significant enough to impact power-sensitive platforms. thanks, Steve