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/13/2013 06:31 PM, Jarzmik, Robert wrote:
> Hi Rafael,
> 
> I came across that little odd behavior in "Suspend to RAM" :
>  1) I do a "chmod audio:audio /sys/devices/system/cpu1/cpufreq/scaling_max_freq (I know, stupid, but it's for the example)
>  2) I do a "echo mem > /sys/power/state"
>  3) I resume the kernel
>      => here the permissions of /sys/devices/system/cpu1/cpufreq/scaling_max_freq have turned back to root:root
> 
> OK, fair well, I add a UDEV rule which does a "chown audio:audio /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq" upon udev event "online, /sys/...".
> And here it becomes interesting :
>  - the udev event "offline" or "online" never comes with the "Suspend to RAM" testcase
>  - but the same udev event comes when I manually do a "echo 0 > /sys/devices/system/cpu/cpu1/online"
> 
> 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.
Put another way, in the future, if we change the kernel code
to do S3 without using hotplug, then there should be no visible
change in userspace, because how S3 is handled in the kernel is
intended to be an "internal" operation. 

Regards,
Srivatsa S. Bhat