All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.