Heterogeneous multi-cores--platforms comprised of both general purpose and accelerator cores--are becoming increasingly common. While applications wish to freely utilize all cores present on such platforms, operating systems continue to view accelerators as specialized devices. The Pegasus system described in this paper uses an alternative approach that offers a uniform resource usage model for all cores on heterogeneous chip multiprocessors. Operating at the hypervisor level, its novel scheduling methods fairly and efficiently share accelerators across multiple virtual machines, thereby making accelerators into first class schedulable entities of choice for many-core applications. Using NVIDIA GPGPUs coupled with x86-based general purpose host cores, a Xen-based implementation of Pegasus demonstrates improved performance for applications by better managing combined platform resources. With moderate virtualization penalties, performance improvements range from 18% to 140% over base GPU driver scheduling when the GPUs are shared.

/pdf/pegasus-coordinated-scheduling-for-virtualized-accelerator-4fnu6txtlx.pdf

Pegasus: coordinated scheduling for virtualized accelerator-based systems

Systems and methods are provided for device playback calibration. An example implementation involves a computing device receiving, via a microphone, detected audio content rendered by at least one playback device. The implementation also involves the computing device modulating the detected audio content with a modulation signal such that the modulation signal has a modulation frequency determined based on an input frequency range of a processing unit. The implementation also involves providing the modulated audio content to the processing unit; and determining, via the processing unit, an equalization setting for the at least one playback device.

Playback device calibration

An example implementation may involve a control device displaying a prompt to initiate a calibration sequence that involves calibration of a playback device for a given environment in which the playback device is located. The example implementation may also involve the control device displaying (i) a prompt to prepare a playback device for calibration within a given environment, (ii) a prompt to prepare the given environment for calibration of the playback device, and/or (iii) a prompt to prepare the control device for calibration of the playback device. The example implementation may also involve a control device displaying a selectable control, that, when selected, initiates calibration of the playback device. The example implementation may further involve a control device initiating calibration of the playback device.

Speaker calibration user interface

Resource management strategies for many-core systems need to enable sharing of resources such as power, processing cores, and memory bandwidth while coordinating the priority and significance of system- and application-level objectives at runtime in a scalable and robust manner. State-of-the-art approaches use heuristics or machine learning for resource management, but unfortunately lack formalism in providing robustness against unexpected corner cases. While recent efforts deploy classical control-theoretic approaches with some guarantees and formalism, they lack scalability and autonomy to meet changing runtime goals. We present SPECTR, a new resource management approach for many-core systems that leverages formal supervisory control theory (SCT) to combine the strengths of classical control theory with state-of-the-art heuristic approaches to efficiently meet changing runtime goals. SPECTR is a scalable and robust control architecture and a systematic design flow for hierarchical control of many-core systems. SPECTR leverages SCT techniques such as gain scheduling to allow autonomy for individual controllers. It facilitates automatic synthesis of the high-level supervisory controller and its property verification. We implement SPECTR on an Exynos platform containing ARM»s big.LITTLE-based heterogeneous multi-processor (HMP) and demonstrate that SPECTR»s use of SCT is key to managing multiple interacting resources (e.g., chip power and processing cores) in the presence of competing objectives (e.g., satisfying QoS vs. power capping). The principles of SPECTR are easily applicable to any resource type and objective as long as the management problem can be modeled using dynamical systems theory (e.g., difference equations), discrete-event dynamic systems, or fuzzy dynamics.

https://dl.acm.org/doi/pdf/10.1145/3173162.3173199

SPECTR: Formal Supervisory Control and Coordination for Many-core Systems Resource Management

An example implementation involves a computing device transmitting, via a local area network, a command that instructs a playback device to play a particular audio signal. The example implementation also involves the computing device receiving data indicating a detected audio signal corresponding to playback of the particular audio signal by the playback device, where the detected audio signal includes a portion of the particular audio signal. The implementation further involves the computing device obtaining data indicating a predetermined audio characteristic and determining an audio processing algorithm based on the detected audio signal and the predetermined audio characteristic. The example implementation involves causing the playback device to apply the determined audio processing algorithm when playing audio via at least one speaker.

Audio processing algorithms

Workload consolidation, whether via use of virtualization or with lightweight, container-based methods, is critically important for current and future datacenter and cloud computing systems. Yet such consolidation challenges the ability of current systems to meet application resource needs and isolate their resource shares, particularly for high core count or 'scaleup' servers. This paper presents the 'Merlin' approach to managing the resources of multicore platforms, which satisfies an application's resource requirements efficiently -- using low cost allocations -- and improves isolation -- measured as increased predictability of application execution. Merlin (i) creates a virtual platform (VP) as a system-level resource commitment to an application's resource shares, (ii) enforces its isolation, and (iii) operates with low runtime overhead. Further, Merlin's resource (re)-allocation and isolation methods operate by constructing online models that capture the resource 'sensitivities' of the currently running applications along all of their resource dimensions. Elevating isolation into a first-class management principle, these sensitivity- and cost-based allocation and sharing methods lead to efficient methods for shared resource use on scaleup server systems. Experimental evaluations on a large core-count machine demonstrate improved performance with reduced performance variation and increased system throughput and efficiency, for a wide range of popular datacenter workloads, compared with the methods used in prior work and with the state-of-art Xen hypervisor.

Merlin: Application- and Platform-aware Resource Allocation in Consolidated Server Systems

A computing device operates to receive, from at least a first peer device, a set of metadata that includes one or more identifiers to media playback resources. The computing device operates to determine one or more filters for the set of metadata. A metadata from the set of metadata is selected based on the one or more filters. A search request is provided to a network service for a media playback resource based on the selected metadata.

Computing device and method for exchanging metadata with peer devices in order to obtain media playback resources from a network service

Recent advances in multi- and many-core architectures include increased hardware-level parallelism (i.e., core counts) and the emergence of platform-level heterogeneity. System software managing these platforms is typically comprised of multiple independent resource managers (e.g., drivers and specialized runtimes) customized for heterogeneous vs. general purpose platform elements. This independence, however, can cause performance degradation for an application that spans diverse cores and resource managers, unless managers coordinate with each other to better service application needs. This paper first presents examples that demonstrate the need for coordination among multiple resource managers on heterogeneous multicore platforms. It then presents useful coordination schemes for a platform coupling an IXP network processor with x86 cores and running web and multimedia applications. Experimental evidence of performance gains achieved through coordinated management motivates a case for standard coordination mechanisms and interfaces for future heterogeneous many-core systems.

/pdf/a-case-for-coordinated-resource-management-in-heterogeneous-2pf9pfp4ge.pdf

A case for coordinated resource management in heterogeneous multicore platforms

An example method of synchronizing application data between a mobile device and a remote computing device includes for each network of one or more networks, collecting network data regarding a mobile device's current connectivity state to the respective network. The mobile device includes one or more mobile applications including application data. The method also includes detecting, at the mobile device, a current connection to a current network. The method further includes comparing one or more opportunity scores for synchronizing application data. The one or more opportunity scores includes an opportunity score for the current network. Each opportunity score is associated with a particular network. The method also includes determining, based on the comparing, whether the current network is a good opportunity network for syncing mobile application data.

Methods and systems for triggering efficient application synchronization

A gateway device may control access to content based, at least in part, on an audience that will consume the content. In relation to a request for content to be delivered to a media output device, the gateway device may obtain biometric data from one or more trait capture devices having a physical relation to the media output device. The gateway can determine the potential audience of the content and enforce content restrictions based on the audience. The content restrictions may be based on one or more content attributes about the content and one or more audience traits about the audience. The gateway may use thresholds associated with the audience trait to determine whether the content attribute is appropriate for the audience. The threshold or a combination of thresholds may provide for granular control of access to content.

Priyanka Tembey

Papers

Merlin: Application- and Platform-aware Resource Allocation in Consolidated Server Systems

Computing device and method for exchanging metadata with peer devices in order to obtain media playback resources from a network service

A case for coordinated resource management in heterogeneous multicore platforms

Methods and systems for triggering efficient application synchronization

Content control at gateway based on audience