Microsoft Technology Licensing, LLC

Samarth Harish Shah

Abolade Gbadegesin

Akhilesh Kaza

Adina Magdalena Trufinescu

Andrew Clinick

David Andrew Whitechapel

Jeremy P Robinson

Timothy Michael Kurtzman

Iulian Doroftei Calinov

Sandeep Prabhakar

Zachary Sandburg Holmes

Taofiq Ezaz

Cenk Ergan

Rahul Nair

Yu Wang

Rico Mariani

Paresh J Maisuria

Eric Ray Hotinger

Steven M Lasker

Jihad Tafas

Bin Du

Tapan Ansel

Gabriel Knezek

Vijay Sundaram

Sajay Antony

Brian Timothy Goff

Siva Garudayagari

Dongjiang You

Shiwei Zhang

James Kennyth Truckle

Joshua Daniel Patterson

Brandon Michael Heenan

Computing system enhancements make container instantiation faster, reduce layer content storage demands, and make more container image formats available. A container instantiation location sends a container image pull request to a container registry, receives an image manifest, sends a layer mount request to the registry instead of a layer content download request, receives a layer mount, optionally repeats for additional layers, creates a union file system spanning the layers, and launches a container process based on the union file system without first downloading all the layer content. Inefficiencies and technical limitations of some other approaches are avoided, such as loopback mounts for snapshot expansion, creation or transmission of extra snapshots or extra container image clones, cluttering layer content with virtual machine settings, container system vendor lock-in, lack of container instantiation at a local system due to insufficient local storage, and lack of syscall optimization due to storage driver plugin usage.

Container instantiation with union file system layer mounts

Embodiments relate to enabling software to interface with a power consumption telemetry system. A process may have tagging instructions that interface with an energy estimation engine. While the energy estimation engine is logging energy consumption by the process, the process may also mark, tag, or otherwise delineate periods of processing during the execution time of the process. The logic of the process may determine how such periods should be labeled and when they being and end. The tagged periods are correlated with energy consumed by the process so that details of what the process was doing during different periods of energy consumption may be understood.

Process-level activity tagging

Consumption of power by device components is profiled on a per-session basis of user interaction. A session engine determines start of a user interaction session with the device (e.g., by detecting screen turn on). The engine generates a session identifier (SID) and broadcasts same to device component(s). In response to the SID, the component(s) record power consumption data. Upon receiving a signal indicating end of the user interaction session (e.g., screen turn off), the session engine broadcasts a notice allowing component(s) to stop recording power consumption data. The components communicate aggregated data to the session engine for storage in a centralized location (e.g., trace buffer). In response to a query posed within a command line prompt, stored data may be parsed on a per-session basis for inclusion in a detailed report of power consumption. Power consumption inefficiencies endemic to components and/or user behaviors may be thus be identified and remediated.

Per-screen on session power consumption profiling

Resources used by a foreground process associated with an application as well as one or more background tasks associated with the application that are running as separate processes on the computing device are tracked. Historical data relating to resource usage by the application is utilized to predict a resource usage amount for the application which is then stored. A subsequent launch of the application can be conditioned upon whether the predicted resource usage amount is available. If the predicted resource usage amount is available, it can be allocated to the application and the application can be launched. If the application then exceeds the predicted resource usage amount, other processes executing concurrently therewith may be terminated to free up the resource. Regardless of how the application performs, new resource usage data is obtained for the application, which is then used to adjust the predicted resource usage amount.

Resource management based on device-specific or user-specific resource usage profiles

Techniques are described that enable an application executing on a computing device to dynamically control how an allocated portion of a resource of the computing device is to be divided among multiple processes associated with the application. For example, an application executing on the computing device may interact with an operating system of the computing device to dynamically control how an allocated portion of a resource of the computing device is to be divided among a foreground process associated with the application and one or more background processes associated with the application.

Dynamic resource management for multi-process applications

Growing community of inventors

Redmond, WA, United States of America

Samarth Harish Shah