On 27.03.19 13:18, Marco Solieri wrote:
Predictability of memory access latency is severely menaced by the multi-core
architectures where the last level of cache (LLC) is shared, jeopardizing
applicability of many Arm platform in real-time critical and mixed-criticality
scenarios. Support for cache coloring is introduced, a transparent software
technique allowing partitioning the LLC to avoid mutual interference between
inmates.

By creating a cache stress environment with a memcpy bare-metal application or
with the Linux "stress" tool, it is easy to measure performance degradations
caused by inter-cell interference, e.g. running the LMBench micro-benchmarks, or
just with the GIC demo within a L1 Instruction stress scenario. Once coloring is
enabled, instead, predictable performances are restored. Reports of extensive
benchmarks and evaluations on real application are referred in the
documentation.

We thanks Tomasz Kloda and Marko Bertogna for the prototype logic and Renato
Mancuso for suggesting low-level design improvements. The EU Horizon 2020 IA
project HERCULES (grant no. 688860) supported the initial implementation and
evaluation on NVIDIA Tegra X1 and X2; Xilinx Inc. supported the implementation
and evaluation on ZCU102; UTRC supported the testing on ZCU104.

A bird-eye view of the implementation and of the commit structure is given.
Some coloring-logic fundamentals are situated in the 'common' part between the
driver and the hypervisor [1], but only the latter implements the whole coloring
support [2]. The hypervisor also exposes a convenient interface to ease the load
operation by the driver [3], who implements a simplified memory allocation
support (only colors have to be chosen) [4] and extends the configuration file
support [5]. Examples root cell and demo configurations are provided for Xilinx
ZCU102 [6] and NVIDIA TX2 [7]. An extensive documentation details the technique
and gently explains how to use it [8].

Luca Miccio (8):
   Common: introduce cache coloring primitives
   Hypervisor: implement cache-colored paging for Arm
   Hypervisor: add hypercall to ease loading of cache-colored images
   Driver: add support for cache-colored memory configurations
   Support cache-colored memory configurations when loading Linux inmate
   Configs: zynqmp-zcu102: add cache-coloring examples
   Configs: jetson-tx2: add cache-coloring examples
   Documentation: add description and usage of cache coloring support

  Documentation/cache-coloring.md              | 330 ++++++++++++
  configs/arm64/jetson-tx2-col.c               | 529 +++++++++++++++++++
  configs/arm64/jetson-tx2-demo-col.c          |  76 +++
  configs/arm64/zynqmp-zcu102-col.c            | 153 ++++++
  configs/arm64/zynqmp-zcu102-demo-col.c       |  79 +++
  configs/arm64/zynqmp-zcu102-linux-demo-col.c | 137 +++++
  driver/Makefile                              |   1 +
  driver/cell.c                                |  56 +-
  driver/coloring.c                            | 239 +++++++++
  driver/coloring.h                            |  52 ++
  driver/main.c                                |   3 +
  hypervisor/arch/arm-common/mmu_cell.c        |  27 +-
  hypervisor/control.c                         |  77 +++
  hypervisor/include/jailhouse/paging.h        |  11 +
  hypervisor/paging.c                          | 168 ++++++
  include/jailhouse/cell-config.h              |   9 +
  include/jailhouse/coloring.h                 | 151 ++++++
  include/jailhouse/hypercall.h                |   1 +
  tools/jailhouse-cell-linux                   |   5 +-
  19 files changed, 2096 insertions(+), 8 deletions(-)
  create mode 100644 Documentation/cache-coloring.md
  create mode 100644 configs/arm64/jetson-tx2-col.c
  create mode 100644 configs/arm64/jetson-tx2-demo-col.c
  create mode 100644 configs/arm64/zynqmp-zcu102-col.c
  create mode 100644 configs/arm64/zynqmp-zcu102-demo-col.c
  create mode 100644 configs/arm64/zynqmp-zcu102-linux-demo-col.c
  create mode 100644 driver/coloring.c
  create mode 100644 driver/coloring.h
  create mode 100644 include/jailhouse/coloring.h


Thanks for updating this! I will refresh my caches on the topic and provide feedback soon (I already have some questions and remarks but I'd like to double-check them).

As you likely read, there are better chances in sight to also address the root cell issue by booting Jailhouse from a loader. That would then leave us only with the question how to handle the hypervisor itself /wrt coloring. Provided that can buy us worthwhile improvements.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

--
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/7e92c41e-12a5-28fd-b1fc-4949e5ccac20%40siemens.com.

Reply via email to