Skip to content

Do resource intensive work opportunistically to reduce interference with user applications #621

@reputhot

Description

@reputhot

Proposal: ActivityCoordinator

To coordinate (start and stop) different activities associated with the work that the user is trying to accomplish.

Summary

The Activity Coordinator API can be used by applications to subscribe to notifications for when it is a good/bad time to run opportunistic background work to help them be well-behaved citizens of the system and run only at appropriate times. The API offers a decision-making model that can be used to determine what an “appropriate time” to perform work is. Opting into the API does not prevent apps from running at inopportune times – it relies on the app to be a good citizen.

Rationale

  • We're always looking to improve the user's experience on Windows. Something that's come up in our feedback and telemetry is non-responsive systems due to CPU load, fast battery drains on mobile devices, high metered network (like cellular) use, and more. Background components like indexers, updaters, or long-running processors can have a direct impact on users' satisfaction with those apps.
  • Windows runs several processes that are required to maintain the daily functioning and health of the system. Some of these processes can be very resource intensive and can be affecting the machine in a way that disrupts user activity. Not all tasks are time constrained and some of the activity can be deferred to run at a time that is more opportunistic for the PC. ActivityCoordinator can be a very useful tool to achieve this.
  • Both Win32 and UWP apps have a lot to gain from the ActivityCoordinator API. Several clients have approached us for using the internal API's and have seen significant improvements upon adoption. Exposing the API as part of Project Reunion would open up possibilities for app developers in creating applications that are more power conscious. Being efficient citizens of the system and running work when it is economical, should not be a developer afterthought, but should be part of early design and development. The API would help the developer achieve this by coordinating background work when it is the best for the system.
  • We currently don't have features that tracks system states in a way that they can be used by end users to perform work opportunistically.
  • Users should be able to define scenarios that are most applicable for their work as "opportunities" can be different for different kinds of work. ActivityCoordinator is able to allow for dynamic policy creation that lets users specify the most opportunistic system conditions.
  • Most users can use the predefined policies, which offers a simple out of the box usage.

Scope

Capability Priority
This proposal will allow developers to accomplish W notify subscribers of opportune times to do resource-intensive work.
This proposal will allow end users to accomplish X Should
This proposal will allow developers to accomplish Y Could
This proposal will allow end users to accomplish Z Won't

Important Notes

API Proposal for Opportunistic Resource-Intensive Work Guidance

We are considering introducing an API that will notify processes of opportune times to do resource-intensive work and will allow processes to minimize impact on the user experience. The API would allow programs to subscribe to notifications of good and bad “work zones” based on a “policy” selected by their developers. The program could then choose to start and stop doing the resource-intensive work in response to the notification.

The developer-supplied policy specifies how opportune of a window the program wants for each of the “dimensions”. The dimensions include CPU, GPU, storage, network, power, and (potential for) user interference. Developers can start with a pre-defined policy and customize it as necessary, or define their own policy from scratch.

Example

Fabrikam has a music player program that can download songs ahead of time to allow offline playback. The music player will generate large playlists based on user. Occasionally it will shuffle some selection of songs out of the rotation and download new ones from the music service. After songs get removed from rotation, they should be deleted to save disk space. Generally, downloading new songs and deleting old ones can be performed opportunistically, except if the user clicks a “generate new playlist” button.

Today, Fabrikam has a 'minimize to tray' option when the music app is not being used. Their background task wakes and checks for updates, shuffles, and maintains their data set every four hours while the user is signed in. Users complain that Fabrikam's app interferes with both work-time meetings and play-time games.

Fabrikam decides to leverage the new API. It identifies that background download of new songs is opportunistic work that may be resource intensive, since it has to download songs, write them to disk, and update the music index. It also identifies that deleting the old songs is also resource intensive. Fabrikam modifies their program to create to subscriptions for the two.

Fabrikam has not profiled playlist refresh, so it selects a default policy and adds a good network condition requirement when creating the playlist refresh subscription. The music player runs playlist refresh when the subscription window indicates it is a good time to do so, or when the user clicks the “generate new playlist” button.

Fabrikam knows that it runs file deletion at low priority, however it can still cause storage interference; Fabrikam creates a completely custom policy that minimizes storage and power impact. Fabrikam’s music player deletes old files when the policy indicates it is a good time to do so.

The users are delighted to find that the program no longer slows down their computer occasionally at seemingly-random times, and their cell phone bills appreciate it too.

We want your feedback!

Is this something you’d be interested in using? Do the dimensions (CPU, GPU, storage, network, power, and (potential for) user interference) meet your requirements? Is a granularity of good/medium/bad sufficient? Do your apps already use background tasks and triggers? What kind of combinations of these dimensions would you want to know about? Let us know what you think!

Open Questions

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions