In Chrome, chromeos::PowerPolicyController is notified about changes to prefs via its ApplyPrefs method. Each time it's called, the class builds up a power_manager::PowerManagementPolicy protobuf and sends it to powerd over D-Bus.

ApplyPrefs is called by chromeos::PowerPrefs, which observes the relevant prefs and passes all of their values to PowerPolicyController whenever one of them changes.

There are cases where a bunch of prefs get updated at once (currently probably only when enterprise policies are changed, but soon when users change settings per  issue 633455 ). When this happens, Chrome makes a separate D-Bus call to powerd for each modified pref. powerd hopefully always ends up in the right place, but the path there is very noisy.

It'd probably be good to find some way to avoid this. Off the top of my head, we could add a very short delay to either PowerPolicyController or PowerPrefs to give us time to collect all of the changes before calling powerd.

Putting this in PowerPrefs feels safer to me. PowerPolicyController gets notified about other things like wake locks and I'd have to think harder to convince myself that deferring notifying powerd about changes to those couldn't have adverse effects.

But I can think of potentially risky sequences even if only PowerPrefs is changed:

1. A wake lock is held.
2. A pref gets changed to keep the system awake.
3. The wake lock is released.

If PowerPrefs waits to tell PowerPolicyController about 2, it's possible that powerd could suspend the system in response to 3 in the meantime.