Multicore Association

       Industry Standards to Solve
       Multicore Challenges

Search this website    

MULTICORE RESOURCE MANAGEMENT API WORKING GROUP

Objective

MRAPI™ is an industry-standard API that specifies essential application-level resource management capabilities. Multicore applications require this API to allow coordinated concurrent access to system resources in situations where:

  1. There are not enough resources to dedicate to individual tasks or processers, and/or
  2. The runtime system does not provide a uniformly accessible mechanism for coordinating resource sharing.

This API is applicable to both SMP and AMP embedded multicore implementations (whereby AMP refers to heterogeneous both in terms of software and hardware). MRAPI (in conjunction with other Multicore Association APIs) can serve as a valuable tool for implementing applications, as well as for implementing such full-featured resource managers and other types of layered services.

Overview

Multicore Resource Management API (MRAPI™) captures the essential capabilities required for managing shared resources in a closely distributed embedded system. These resources include multiple, homogeneous or heterogeneous cores or chips, hardware accelerators, memory regions, and I/O. MRAPI™ supports the ability to declare and allocate/destroy shared memory regions and to identify nodes which have access to each region. MRAPI™ also provides application-level synchronization primitives for coordinating access to shared resources. MRAPI supports queries regarding static and dynamic resources, and it supports system-level event notification such as power-savings states, device failures, and hypervisor repartitioning. It allows coordinated concurrent access to system resources in situations where (a) there are too few resources to dedicate to individual tasks or processors, and/or (b) the runtime system does not provide a uniformly accessible mechanism for coordinating resource-sharing.

MRAPI is scalable and can support virtually any number of cores, each with a different processing architecture and each running the same or a different operating system, or no OS at all. As such, MRAPI is intended to provide source-code compatibility that allows applications to be ported from one operating environment to another.

Status

The MRAPI™ working group has completed the first version of this specification.

Chairpersons

  • Jim Holt, Manager, Processor Core Architecture, Freescale Semiconductor
  • Sven Brehmer, President, PolyCore Software

Primary Contributing Members

Codeplay Software, Freescale, IBM, IMEC, LSI Corporation, Mentor Graphics, PolyCore Software, Samsung, Texas Instruments, Tilera

Frequently Asked Questions about MRAPI™


Q: How will hardware accelerators interact with embedded processors using MRAPI? Since an API is a library of C/C++ functions, it is not clear how an API can be used with a hardware accelerator, which can be very application specific.
A: The API can be implemented on top of a hardware accelerator. For example, an SoC may have hardware acceleration for mutexes, in which case an MRAPI implementation could utilize that hardware accelerator without the programmer needing to know how to interact with it directly.

Q: How does this API ask for HW accelerators if these accelerators are actually powered off because of inactivity?
A: In such a scenario the application would determine that there was no acceleration available and would have to find an alternative means to perform its work, perhaps by executing code on the CPU.

Q: Does MRAPI rely upon a "local" resource manager? That is, does MRAPI store state and need a way to allocate state storage?
A: It is up to the MRAPI implementation as to how resources are managed. Our simple initial implementation stores state in shared memory protected with a semaphore.

Q: I saw a statement that other solutions are too heavyweight because they target distributed systems. Does it mean that your goal is not to target the distributed system? What happens when we have a multi-chip multi-core? Isn't this the same distributed system?
A: MRAPI targets cores on a chip, and chips on a board. MRAPI is not intended to scale beyond that scope.

Q: Is it possible to hide the differences between local and remote memory by just different properties of these memories? Remote memory will have higher latency, some access restrictions, etc.
A: The working group has considered the possibility of allowing the “promotion” of local memory to remote memory, and then allowing all memory accesses to occur through the API. This would effectively hide the difference, but at a performance cost. For now this is a deferred feature.

Q: In many HW systems, transitions between low power (or no power) and fully working conditions are extremely frequent. In such systems some state change callbacks will become a nightmare. How does MRAPI handle the situation?
A: In the situation where the application does not want to be disturbed by frequent callbacks, then it would be better for the application to periodically poll MRAPI at a time of its own choosing. This is certainly possible with MRAPI.

Q: Are there any plans to include trigger APIs? For example, invoke callback when a particular resource hits some pre-defined conditions/threshold?
A: Currently there are no threshold-related callbacks other than counter wrap-arounds. MRAPI may consider this for a future version.

Q: Primitives - did you consider including read-copy-update (RCUs)?
A: The MRAPI working group did consider read copy update locks. After discussion with some of the original creators of the RCU code for Linux, we determined that for now there is not sufficient evidence that a high performance, user-level implementation of RCU was feasible. We intend to monitor developments as we are aware that it is an active area of research.

Q: These primitives included in MRAPI are necessary, but seem to be insufficient. Shouldn’t a goal of MRAPI be to include the ability to write a resource manager that any app that uses MRAPI could plug into. That implies that at a minimum: resource enumerations should be standardized or a mechanism for self-describing enumerations be created.
A: MRAPI is intended to provide some of the primitives that could be used for creating a higher level resource manager. However, it is also intended to be useful for application level programmers to write multicore code, and for this reason it was kept minimal and orthogonal to other Multicore Association APIs. The working group believes that a full-featured resource manager would require all of the Multicore Association APIs, e.g., MCAPI, MRAPI, and MTAPI.

Q: Are any companies currently incorporating or have plans to incorporate MRAPI in their products. If so, can you name the products?
A: At this time there have been no public announcements. There is at least one university research project that is looking at MRAPI for heterogeneous multicore computing. We expect more activities to emerge soon.


Become a member of The Multicore Association today, don’t let the multicore revolution leave you behind.
© 2012
The Multicore Association. All rights reserved. Cookies must be turned on in your browser to use some of the features of this website.
Website designed and maintained by Degive Enterprises.