Re: S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq

["Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>]

On 05/14/2013 02:36 PM, Jarzmik, Robert wrote:
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
> Sent: Tuesday, May 14, 2013 1:33 AM
> To: Srivatsa S. Bhat; Jarzmik, Robert
> Cc: linux-pm@vger.kernel.org
> Subject: Re: S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq
> 
>>> So my question is : is it intended behavior that no udev offline/online event happens on S3 for non-boot CPUs, or is it something I should try to fix ?
>>
>> IMHO, using CPU hotplug (offline/online of CPUs) in the S3 path is 
>> supposed to be totally internal to the suspend/resume code.
>> It is not intended for userspace to know that we are internally 
>> offlining/onlining CPUs. So I'm not surprised that udev events are not 
>> triggered for hotplug in S3 path. And that's not a bug, if you ask me. 
>> (And yes, even code-wise, we use a slightly different path in the S3 
>> code, to initiate hotplug. That's why the uevents are by-passed.)
>>
>> The user initiated an S3 operation, not CPU hotplug. So there is no 
>> reason to surprise the user with unexpected events.
> Hi Srivatsa,
> 
> But the user actually *is* very surprised to have "lost" his
> permissions to write to scaling_max_freq.

And losing permissions isn't specific to suspend-to-ram right?
You said that yourself, that on regular cpu online/offline you lose
the changed permissions. So just write a resume hook to restore whatever
permissions you want after suspend-resume. See /usr/lib64/pm-utils/sleep.d
for some sample resume scripts.

> Or, told differently,
> if a userspace process handles this scaling_max_freq based on
> thermal values for example, a suspend/resume will impede his
> capacity to throttle the CPU, and the CPU will overheat.
> 
> A good example is an Android phone : imagine the thermal will not
> be able anymore to throttle the CPU, the phone will become hot
> and possibly burn the user (yeah, that's not very probable but
> still ...).
> 
> So you say "there is no reason to surprise the user with
> unexpected events", and I say "this is a bug that permissions of
> a /sys file change because a suspend/resume happened". Now if I'm
> right, what could be done to keep these permissions, other than
> adding a udev event ?
> 

The point I was trying to make is that expecting udev events for
CPU online/offline during S3 is wrong. Nobody is supposed to know that
we are offlining/onlining CPUs under-the-hood.
If you want to do something special on resume, use a resume script
that is automatically invoked for you upon system resume.

Regards,
Srivatsa S. Bhat