Research Paper: MDAG Containers Connected Standby Support

This document sums up the requirements for supporting Connected Standby on CMS containers and details a design for MDAG Containers.

1. Introduction

1.1. Connected Standby

Connected Standby (CS) is a low-power idle that allows Windows to keep the system alive to process background tasks. A CS session comprises Screen Off and Sleep states. During Screen Off, Windows prepares apps and system software for low-power mode and enters a Sleep state where the SOC is powered off. The system periodically wakes up to run scheduled tasks.

1.2. Need for CS Support for MDAG containers

To ensure containers stop activities and power drain during Connected Standby, CMS sends CS-Stop requests to containers that support it. MDAG containers do not handle stop requests and are currently excluded from the CS flow. As a result, they do not suspend during Connected Standby and run through Screen Off until they stop getting scheduled when the device enters Sleep. The containers also continue execution every time the system wakes up for scheduled tasks.

Powercfg.exe tool’s SleepStudy indicated an obvious battery drain (attributed to ‘System’) when devices  went to sleep with the Edge container running. MDAG container’s power consumption throughout Screen Off and the periodic wakeups during Sleep can be avoided if we implement CM’s CS workflow requirement.

1.3. CMS Activities CS workflow

CMS sends CS-Stop requests for a container through the container’s Activities.

An Activity represents work that requires a container to be running. Traditionally, CM guarantees that a container does not get suspended if it has an Activity running. However, for containers that support CS, CMS can request that Activities be stopped through stop requests sent to the Activity notification callback. After sending a stop request, CM transitions the Activity to a stop-pending state during which CM still guarantees liveness, but the client is expected to perform any clean-up work and close the Activity as soon as possible, within a 1 min limit. After this, liveness is no longer guaranteed, and CMS may suspend the container.

For containers that need to resume when the device wakes up, like in the case of MDAG, clients can stop and close their Activity and immediately start a new one. The new Activity will remain in a start pending state until CMS can grant it again after the device exits CS.

To support the workflow above, MDAG needs to handle stop requests sent to Activities created for containers by stopping and recreating them.

2. Design Assumptions

The design below uses the first stop request received for any Activity as a signal to stop and recreate all Activities for all MDAG containers. This assumes all containers/Activities will get a stop request if any of them gets one.

3. Design

On a high level, Hvsics will propagate stop request from CM to Hvsimgr. Hvsimgr then ensures all containers stop to comply with the request but get resumed when the device wakes up from CS. The sections below detail how this will be done.

3.1. MDAG Container Activities

Hvsics creates more than one Activity for each container: one to start and keep the container running and other to change container priority. Although each Activity receives a stop request, we will treat running Activities as a single unit such that the first stop notification initiates stop of all activities for a container and other notifications ignored. We can additionally use the same model for all MDAG containers: as all running containers will eventually need to suspend, we can use the first request to initiate stop for all running containers.

3.2. Receiving stop requests

CM already requires callbacks be specified to receive notifications for created Activities. The current callback can be extended to additionally process Activity stop requests.

3.3. Passing stop request to Hvsimgr

Although Hvsics creates container Activities and supplies the notification callback, Hvsimgr manages container state and initiates all state changes, so Hvsics needs to pass on stop request notifications to Hvsimgr. Hvsimgr also needs to notify Hvsics when it has completed handling a stop request.

A single global named event can be used for both communications. Hvsics and Hvsimgr will share a StopRequest event with a pre-agreed static or, if needed, dynamic name. Upon receiving a stop request, the notification callback in Hvsics will signal the event if it is not already in a signaled state. Until the event is reset, the subsequent stop notifications for other MDAG activities are ignored.

3.4. Receiving and handling stop request in Hvsimgr

On the Hvsimgr side, a thread will monitor for the StopRequest event to be set by Hvsics, indicating receipt of a stop request.

As suspending a container stops all Activities running for the container and resuming it restarts the stopped activities, Hvsimgr can fast suspend all containers to satisfy CM’s requirement that Activities be stopped and then attempt to resume them.

Since resume creates and waits for CM to grant and start an activity, containers will not resume until the device wakes up and CM starts granting Activities again.

3.5. Resetting StopRequest event

Once all containers are suspended, no Activities can be running, and Hvsics will not receive additional stop request notifications. Hvsimgr will reset the StopRequest event at this point and before attempting to resume any containers. This additionally ensures Hvsimgr will not miss any stop requests for containers that it has resumed.