Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756057AbcCCCtV (ORCPT ); Wed, 2 Mar 2016 21:49:21 -0500 Received: from mail-lb0-f176.google.com ([209.85.217.176]:35753 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751891AbcCCCtT (ORCPT ); Wed, 2 Mar 2016 21:49:19 -0500 MIME-Version: 1.0 In-Reply-To: <20160302074910.10178.35029@quark.deferred.io> References: <1456190570-4475-1-git-send-email-smuckle@linaro.org> <1456190570-4475-4-git-send-email-smuckle@linaro.org> <8427745.Y8N2bqC3SO@vostro.rjw.lan> <56CF9D8F.7010607@linaro.org> <20160302074910.10178.35029@quark.deferred.io> Date: Thu, 3 Mar 2016 03:49:17 +0100 X-Google-Sender-Auth: 9ON9TnyG6yut0WYfP8SYi1G3saw Message-ID: Subject: Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection From: "Rafael J. Wysocki" To: Michael Turquette Cc: Steve Muckle , "Rafael J. Wysocki" , Peter Zijlstra , Ingo Molnar , "Rafael J. Wysocki" , Linux Kernel Mailing List , "linux-pm@vger.kernel.org" , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Ricky Liang 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: 1727 Lines: 42 On Wed, Mar 2, 2016 at 8:49 AM, Michael Turquette wrote: > [cut] > I do not have any data to back up a case for stalls caused by RT/DL > starvation, but conceptually I would say that latency is fundamentally > more important in a scheduler-driven cpu frequency selection scenario, > versus the legacy timer-based governors. > > In the latter case we get woken up by a timer (prior to Rafael's recent > "cpufreq: governor: Replace timers with utilization update callbacks" > patch), we sample idleness/busyness, and change frequency, all in one go > and all from process context. > > In the case of the scheduler selecting frequency in the hot path, with > hardware that takes a long time to transition frequency (and thus must > be done in a slow path), we want to minimize the time delta between the > scheduler picking a frequency and the thread that executes that change > actually being run. That is a good point. However, the Peter's one about the RT tasks having to run at the max util and affecting the frequency control this way is good too. I'm not actually sure if RT is the right answer here. DL may be a better choice. After all, we want the thing to happen shortly, but not necessarily at full speed. So something like a DL workqueue would be quite useful here it seems. > In my over-simplified view of the scheduler, it would be great if we > could have a backdoor mechanism to place the frequency transition > kthread onto a runqueue from within the schedule() context and dispense > with the irq_work stuff in Steve's series altogether. Well, I use irq_work() now in schedutil and ondemand/conservative too for queuing up work items and it gets the job done. Thanks, Rafael