From: Saravana Kannan <skannan@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Prarit Bhargava <prarit@redhat.com>,
Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Srivatsa Bhat <srivatsa@mit.edu>
Subject: Re: [PATCH V2 00/20] cpufreq: Don't loose cpufreq history on CPU hotplug
Date: Fri, 27 Feb 2015 18:36:42 -0800 [thread overview]
Message-ID: <54F129BA.3030202@codeaurora.org> (raw)
In-Reply-To: <CAKohponfFhGCAm8Dn_9V4doLhJzt6362q31Ub2nC9C3+o1Mvug@mail.gmail.com>
On 02/26/2015 09:26 PM, Viresh Kumar wrote:
> On 19 February 2015 at 17:02, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> Hi Rafael,
>>
>> The aim of this series is to stop managing cpufreq sysfs directories on CPU
>> hotplugs.
>>
>> Currently on removal of a 'cpu != policy->cpu', we remove its sysfs directories
>> by removing the soft-link. And on removal of policy->cpu, we migrate the sysfs
>> directories to the next cpu. But if policy->cpu was the last CPU, we remove the
>> policy completely and allocate it again as soon as the CPUs come back. This has
>> shortcomings:
>>
>> - Code Complexity
>> - Slower hotplug
>> - sysfs file permissions are reset after all policy->cpus are offlined
>> - CPUFreq stats history lost after all policy->cpus are offlined
>> - Special management of sysfs stuff during suspend/resume
>>
>>
>> To make things simple we stop playing with sysfs files unless the driver is
>> getting removed. Also the policy is kept intact to be used later.
>>
>> First few patches provide a clean base for others *more important* patches.
>>
>> Rebased-over: your bleeding edge branch as there were dependencies on my earlier
>> patches.
>>
>> Pushed here:
>>
>> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/core/sysfs
>>
>> v1->V2:
>> - Dropped the idea of using policy-lists for getting policy for any cpu
>> - Also dropped fallback list and its per-cpu variable
>> - Stopped cleaning cpufreq_cpu_data and doing list_del(policy) on logical
>> hotplug.
>> - Added support for physical hotplug of CPUs (Untested).
>
> Gentle reminder for reviews !! :)
>
Sorry, caught up on some internal work. Should be able to get to this by
Wednesday.
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-02-28 2:36 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 11:32 [PATCH V2 00/20] cpufreq: Don't loose cpufreq history on CPU hotplug Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 01/20] cpufreq: Add doc style comment about cpufreq_cpu_{get|put}() Viresh Kumar
2015-03-20 0:34 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 02/20] cpufreq: Merge __cpufreq_add_dev() and cpufreq_add_dev() Viresh Kumar
2015-03-20 0:34 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 03/20] cpufreq: Throw warning when we try to get policy for an invalid CPU Viresh Kumar
2015-03-20 0:34 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 04/20] cpufreq: Keep a single path for adding managed CPUs Viresh Kumar
2015-03-20 0:37 ` Saravana Kannan
2015-03-20 3:16 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 05/20] cpufreq: Clear policy->cpus even for the last CPU Viresh Kumar
2015-03-20 0:43 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 06/20] cpufreq: Create for_each_{in}active_policy() Viresh Kumar
2015-03-20 1:01 ` Saravana Kannan
2015-03-20 4:41 ` Viresh Kumar
2015-03-20 19:18 ` Saravana Kannan
2015-05-07 22:11 ` Rafael J. Wysocki
2015-05-08 2:33 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 07/20] cpufreq: Call schedule_work() for the last active policy Viresh Kumar
2015-04-02 3:40 ` Saravana Kannan
2015-04-02 5:02 ` Viresh Kumar
2015-05-07 22:13 ` Rafael J. Wysocki
2015-05-08 2:36 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 08/20] cpufreq: Don't clear cpufreq_cpu_data and policy list for inactive policies Viresh Kumar
2015-04-02 4:14 ` Saravana Kannan
2015-04-02 5:11 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 09/20] cpufreq: Get rid of cpufreq_cpu_data_fallback Viresh Kumar
2015-04-02 4:20 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 10/20] cpufreq: Don't traverse list of all policies for adding policy for a cpu Viresh Kumar
2015-04-02 4:24 ` Saravana Kannan
2015-02-19 11:32 ` [PATCH V2 11/20] cpufreq: Manage governor usage history with 'policy->last_governor' Viresh Kumar
2015-04-02 4:34 ` Saravana Kannan
2015-04-02 5:26 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 12/20] cpufreq: Mark policy->governor = NULL for inactive policies Viresh Kumar
2015-04-02 4:38 ` Saravana Kannan
2015-04-02 6:09 ` Viresh Kumar
2015-04-04 1:20 ` Saravana Kannan
2015-04-04 3:07 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 13/20] cpufreq: Don't allow updating inactive-policies from sysfs Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 14/20] cpufreq: Track cpu managing sysfs kobjects separately Viresh Kumar
2015-04-02 4:40 ` Saravana Kannan
2015-04-02 5:41 ` Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 15/20] cpufreq: Stop migrating sysfs files on hotplug Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 16/20] cpufreq: Remove cpufreq_update_policy() Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 17/20] cpufreq: Initialize policy->kobj while allocating policy Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 18/20] cpufreq: Call cpufreq_policy_put_kobj() from cpufreq_policy_free() Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 19/20] cpufreq: Restart governor as soon as possible Viresh Kumar
2015-02-19 11:32 ` [PATCH V2 20/20] cpufreq: Add support for physical hoplug of CPUs Viresh Kumar
2015-02-27 5:26 ` [PATCH V2 00/20] cpufreq: Don't loose cpufreq history on CPU hotplug Viresh Kumar
2015-02-28 2:36 ` Saravana Kannan [this message]
2015-03-16 9:45 ` Viresh Kumar
2015-03-17 22:13 ` Saravana Kannan
2015-03-26 11:59 ` Viresh Kumar
2015-03-26 20:28 ` Rafael J. Wysocki
2015-03-26 20:41 ` Saravana Kannan
2015-03-27 5:15 ` Viresh Kumar
2015-03-20 0:33 ` Saravana Kannan
2015-05-07 22:18 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F129BA.3030202@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=prarit@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=srivatsa@mit.edu \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).