From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow
Date: Thu, 25 Feb 2016 16:50:29 -0800
Message-ID: <20160226005029.2278.38972@quark.deferred.io>
References: <1456190570-4475-1-git-send-email-smuckle@linaro.org>
 <1456190570-4475-3-git-send-email-smuckle@linaro.org>
 <CAJZ5v0gM56y0+_SCV5RDQzWWJxS_aNWWpi8ZrcGtjZo+fH2uUA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8BIT
Return-path: <linux-pm-owner@vger.kernel.org>
Received: from mail-pa0-f46.google.com ([209.85.220.46]:34874 "EHLO
	mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753155AbcBZBAU convert rfc822-to-8bit (ORCPT
	<rfc822;linux-pm@vger.kernel.org>); Thu, 25 Feb 2016 20:00:20 -0500
Received: by mail-pa0-f46.google.com with SMTP id ho8so42410557pac.2
        for <linux-pm@vger.kernel.org>; Thu, 25 Feb 2016 17:00:20 -0800 (PST)
In-Reply-To: <CAJZ5v0gM56y0+_SCV5RDQzWWJxS_aNWWpi8ZrcGtjZo+fH2uUA@mail.gmail.com>
Sender: linux-pm-owner@vger.kernel.org
List-Id: linux-pm@vger.kernel.org
To: Steve Muckle <steve.muckle@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, Vincent Guittot <vincent.guittot@linaro.org>, Morten Rasmussen <morten.rasmussen@arm.com>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Juri Lelli <Juri.Lelli@arm.com>, Patrick Bellasi <patrick.bellasi@arm.com>, Viresh Kumar <viresh.kumar@linaro.org>

Quoting Rafael J. Wysocki (2016-02-22 17:31:09)
> On Tue, Feb 23, 2016 at 2:22 AM, Steve Muckle <steve.muckle@linaro.org> wrote:
> > From: Michael Turquette <mturquette@baylibre.com>
> >
> > Some architectures and platforms perform CPU frequency transitions
> > through a non-blocking method, while some might block or sleep. Even
> > when frequency transitions do not block or sleep they may be very slow.
> > This distinction is important when trying to change frequency from
> > a non-interruptible context in a scheduler hot path.
> >
> > Describe this distinction with a cpufreq driver flag,
> > CPUFREQ_DRIVER_FAST. The default is to not have this flag set,
> > thus erring on the side of caution.
> >
> > cpufreq_driver_is_slow() is also introduced in this patch. Setting
> > the above flag will allow this function to return false.
> >
> > [smuckle@linaro.org: change flag/API to include drivers that are too
> >  slow for scheduler hot paths, in addition to those that block/sleep]
> >
> > Cc: Rafael J. Wysocki <rafael@kernel.org>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Signed-off-by: Michael Turquette <mturquette@baylibre.com>
> > Signed-off-by: Steve Muckle <smuckle@linaro.org>
> 
> Something more sophisticated than this is needed, because one driver
> may actually be able to do "fast" switching in some cases and may not
> be able to do that in other cases.

Those drivers can set the flag dynamically when they probe based on
their ACPI tables.

> 
> For example, in the acpi-cpufreq case all depends on what's there in
> the ACPI tables.

It's all a moot point until the locking in cpufreq is changed. Until
those changes are made it is a bad idea to call cpufreq_driver_target()
from schedule() context, regardless of the underlying hardware, and all
platforms should kick that work out to the kthread.

Regards,
Mike

> 
> Thanks,
> Rafael