Specific read only data management for memory hierarchy optimization

Abstract

The multiplication of the number of cores inside embedded systems has raised the pressure on the memory hierarchy. The cost of coherence protocol and the scalability problem of the memory hierarchy is nowadays a major issue. In this paper, a specific data management for read-only data is investigated because these data can be duplicated in several memories without being tracked. Based on analysis of standard benchmarks for embedded systems, this analysis shows that read-only data represent 62% of all the data used by applications and 18% of all the memory accesses. A specific data path for read-only data is then evaluated by using simulations. On the first level of the memory hierarchy, removing read-only data of the L1 cache and placing them in another read-only cache improve the data locality of the read-write data by 30% and decrease the total energy consumption of the first level memory by 5%.

On Kubernetes-aided Federated Database Systems

“…Some applications can completely be based on the readonly datasets, e.g., the online dictionary 8 and the postal code lookup wizard 9 . More specifically, by analysing the standard benchmarks for embedded systems, it is estimated that up to 62% of all the data used by applications are read-only [5].…”

“…A service can not only abstract the definition and the access policy of pods, but can also abstract other kinds of back-end endpoints. 5 For example, given a standalone query engine (see Query engine below) that offer single query capabilities for a federated component system, we can manually create an Endpoints object for it and map its network address to a standard Kubernetes service. Note that the behaviours of such an engine service will have no difference to the basic DB services.…”

“…From the application's perspective, most of the geospatial and theme data (e.g., postal code) are pre-obtained and fixed in our WebGIS project. In fact, more than half of the data used by real-world applications are read-only [5]. From the technological perspective, our container-native read-only DB solution significantly simplifies the tech stack for building a Kubernetes-aided FDBS.…”