It looks like Chrome unconditionally freezes renderers on suspend and thaws them on resume:

- Chrome tests for the existence of /sys/fs/cgroup/freezer/chrome_renderers/cgroup.procs, /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen/cgroup.procs, and /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen/freezer.state
- ui.conf unconditionally creates /sys/fs/cgroup/freezer/chrome_renderers and /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen

We really only need freezing when dark resume is enabled[1].

The code is somewhat tricky and contained a race that was fixed recently ( issue 646912 ). It has unit tests now, but it might still be better to not run it when we don't need to. Chrome doesn't currently have any way to determine whether dark resume is enabled, though.

From Chirantan: "Disabling it when dark resume is disabled sounds good to me.  There is a pref for keeping wifi on during sleep (prefs::kWakeOnWifiDarkConnect) but that's tied to the primary profile so I'm not sure it's available until the primary user logs in.

"Alternatively we could have chrome query powerd to see if dark resume is enabled and take an appropriate action based on the reply."

Another option might be adding a field to the protobuf sent with SuspendImminent stating that dark resume is enabled. Chrome would lazily create the freezer on the first suspend of the session, then; I'm not sure if that would be problematic or not.

----

1. Which it apparently ought not to be anywhere right now, although it sounds like it's possible that we missed a few boards. I think that powerd defaults to enabling it when the kernel interface is available; we set a disable_dark_resume pref for elm, samus, and lulu, but not for e.g. link.