From: Saravana Kannan <skannan@codeaurora.org>
To: Todd Poynor <toddpoynor@google.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Srivatsa S. Bhat" <srivatsa@mit.edu>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
Linux PM mailing list <linux-pm@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Ruchi Kandoi <kandoiruchi@google.com>
Subject: Re: RFC: Leave sysfs nodes alone during hotplug
Date: Mon, 07 Jul 2014 18:18:05 -0700 [thread overview]
Message-ID: <53BB46CD.9070406@codeaurora.org> (raw)
In-Reply-To: <CAAW3Ypa690EKmDzwx94CaHeR4j_F6_yFmFrn6xTYuLv=pH7B3g@mail.gmail.com>
On 07/07/2014 03:40 PM, Todd Poynor wrote:
> On Mon, Jul 7, 2014 at 12:30 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> ...
>>> Though these are the requirements I have from them:
>>> - On hotplug files values should get reset ..
>>> - On suspend/resume values must be retained.
>>
>> Hmm... There's actually enough interest in NOT reseting across hotplug
>> because it's also used by thermal when a CPU gets too hot and then it's
>> plugged in later. So, userspace has no way to cleanly restore the values.
>> But that's a separate topic.
>
> For Android's usage we're also interested in both:
>
> 1. not removing and recreating the cpufreq sysfs files for a CPU on
> hotplug events (we currently use hotplug uevents to reset file
> ownership such that power policy can be controlled by non-root).
Ah thanks! This is another good point towards leaving the sysfs nodes
alone that I forgot about.
> 2. not resetting the contents of policy files such as scaling_max_freq
> (also fixed up from uevents) or stats files (we currently keep a
> separate persistent time_in_state for battery accounting purposes).
>
>>>> Any objections to leaving them alone during hotplug? If those files are
>>>> read/written to when the entire cluster is hotplugged off, we could just
>>>> return an error. I'm not saying it would be impossible to fix all these
>>>> deadlock and race issues in the current code -- but it seems like a lot
>>>> of
>>>> pointless effort to remove/add sysfs nodes.
>
> No objections from our standpoint.
>
Thanks,
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: RFC: Leave sysfs nodes alone during hotplug
Date: Mon, 07 Jul 2014 18:18:05 -0700 [thread overview]
Message-ID: <53BB46CD.9070406@codeaurora.org> (raw)
In-Reply-To: <CAAW3Ypa690EKmDzwx94CaHeR4j_F6_yFmFrn6xTYuLv=pH7B3g@mail.gmail.com>
On 07/07/2014 03:40 PM, Todd Poynor wrote:
> On Mon, Jul 7, 2014 at 12:30 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> ...
>>> Though these are the requirements I have from them:
>>> - On hotplug files values should get reset ..
>>> - On suspend/resume values must be retained.
>>
>> Hmm... There's actually enough interest in NOT reseting across hotplug
>> because it's also used by thermal when a CPU gets too hot and then it's
>> plugged in later. So, userspace has no way to cleanly restore the values.
>> But that's a separate topic.
>
> For Android's usage we're also interested in both:
>
> 1. not removing and recreating the cpufreq sysfs files for a CPU on
> hotplug events (we currently use hotplug uevents to reset file
> ownership such that power policy can be controlled by non-root).
Ah thanks! This is another good point towards leaving the sysfs nodes
alone that I forgot about.
> 2. not resetting the contents of policy files such as scaling_max_freq
> (also fixed up from uevents) or stats files (we currently keep a
> separate persistent time_in_state for battery accounting purposes).
>
>>>> Any objections to leaving them alone during hotplug? If those files are
>>>> read/written to when the entire cluster is hotplugged off, we could just
>>>> return an error. I'm not saying it would be impossible to fix all these
>>>> deadlock and race issues in the current code -- but it seems like a lot
>>>> of
>>>> pointless effort to remove/add sysfs nodes.
>
> No objections from our standpoint.
>
Thanks,
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-07-08 1:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 21:59 RFC: Leave sysfs nodes alone during hotplug Saravana Kannan
2014-07-03 21:59 ` Saravana Kannan
2014-07-07 11:01 ` Viresh Kumar
2014-07-07 11:01 ` Viresh Kumar
2014-07-07 19:30 ` Saravana Kannan
2014-07-07 19:30 ` Saravana Kannan
2014-07-07 22:40 ` Todd Poynor
2014-07-07 22:40 ` Todd Poynor
2014-07-08 1:18 ` Saravana Kannan [this message]
2014-07-08 1:18 ` Saravana Kannan
2014-07-08 2:40 ` Viresh Kumar
2014-07-08 2:40 ` Viresh Kumar
2014-07-08 3:30 ` skannan
2014-07-08 3:30 ` skannan at codeaurora.org
2014-07-08 4:21 ` Viresh Kumar
2014-07-08 4:21 ` Viresh Kumar
2014-07-10 2:40 ` Saravana Kannan
2014-07-10 2:40 ` Saravana Kannan
2014-07-08 2:36 ` Viresh Kumar
2014-07-08 2:36 ` Viresh Kumar
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=53BB46CD.9070406@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=cpufreq@vger.kernel.org \
--cc=kandoiruchi@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=srivatsa@mit.edu \
--cc=toddpoynor@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.