Modularisierung von ION-Heaps für GKI

Viele Android-OEMs ändern den ION-Kerneltreiber aus verschiedenen Gründen, z. B. durch das Hinzufügen von Hersteller-Heaps und das Anpassen der Cache-Verwaltung (Einzelheiten zu diesen Änderungen finden Sie unter „Integration des ION-Speicherzuweisers “). Damit OEMs solche Änderungen beibehalten können, wenn sie das Generic Kernel Image (GKI) verwenden, führt Android Common Kernel v5.4 ein Framework zur Modularisierung herstellerspezifischer ION-Heaps ein, während der Kern-ION-Treiber integriert bleibt. Die folgende Abbildung zeigt das Kernel-Image-Layout .

Modulare ION-Haufen

Abbildung 1. Modularisierter ION-Kernel-Treiber

Modulare ION-Heaps bieten die folgenden Vorteile.

  • Der ION-Kerntreiber kann Teil des GKI-Images sein, sodass alle geräteunabhängigen Leistungsoptimierungen und Fehlerbehebungen alle Geräte erreichen können.
  • Der ION-Kerntreiber im gemeinsamen Kernel kann die Heap-Registrierung übernehmen und die Schnittstelle zu Userspace- und Kernel-Clients verwalten. Die Heap-Module des Anbieters sind nur zum Implementieren der benutzerdefinierten Heap-Vorgänge erforderlich.
  • Der ION-Kerntreiber (als Teil des GKI) kann Hooks für eine einfachere Verfolgung der Speichernutzung enthalten, was nicht möglich war, als jeder OEM seine eigene Version des ION-Treibers hatte.
  • Modulare ION-Heaps von Anbietern sollten künftige Umstellungen auf dmabuf Heaps erleichtern.

Umsetzung

ION-Heap-Module können ihre eigenen dmabuf Vorgänge registrieren, um die vom ION-Kerntreiber registrierten Vorgänge zu überschreiben. Eine dmabuf Operation (z. B. get_flags() ), die vom ION-Kerntreiber nicht unterstützt wird, gibt -EOPNOTSUPP zurück, wenn der Heap-Implementierung die erforderlichen Überschreibungen fehlen.

Um die Leistung zu verbessern, kann der dmabuf Treiber eine teilweise Cache-Wartung durchführen (siehe Änderungsliste ). Kernel-Clients können die Funktionen dma_buf_begin_cpu_access_partial und dma_buf_end_cpu_access_partial verwenden, um eine teilweise Cache-Wartung durchzuführen.

Der Android Common Kernel enthält modulare Implementierungen des Systems und CMA-Heaps (Contiguous Memory Allocator) zur Verwendung als Referenz für die Heap-Modularisierung.

Änderungen am ION UAPI-Header

Der ION User Space API (UAPI)-Header enthält eine ion_heap_id Enumeration zur Verwendung beim Definieren eines Bereichs von Heap-IDs zur Verwendung durch Anbieter-Heaps.

 /**
 * ion_heap_id - list of heap IDs that Android can use
 *
 * @ION_HEAP_SYSTEM        ID for the ION_HEAP_TYPE_SYSTEM
 * @ION_HEAP_DMA_START     Start of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
 * @ION_HEAP_DMA_END       End of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
 * @ION_HEAP_CUSTOM_START  Start of reserved ID range for heaps of custom type
 * @ION_HEAP_CUSTOM_END    End of reserved ID range for heaps of custom type
 */

enum ion_heap_id {

   ION_HEAP_SYSTEM = (1 << ION_HEAP_TYPE_SYSTEM),

   ION_HEAP_DMA_START = (ION_HEAP_SYSTEM << 1),

   ION_HEAP_DMA_END = (ION_HEAP_DMA_START << 7),
   ION_HEAP_CUSTOM_START = (ION_HEAP_DMA_END << 1),

   ION_HEAP_CUSTOM_END = (ION_HEAP_CUSTOM_START << 22),
};

Darüber hinaus kann eine neue IOCTL ( ION_IOC_ABI_VERSION ) User-Space-Clients dabei helfen, festzustellen, ob modulare Heaps verwendet werden.

Überschreiben des generischen Systemheaps

Der ION-System-Heap ist integriert und Teil des GKI-Images, um sicherzustellen, dass jede Funktion, die Zugriff auf einen generischen/geräteunabhängigen Heap benötigt, von dessen Existenz abhängig sein kann. Daher können Sie die Heap-ID von ION_HEAP_SYSTEM nicht überschreiben. Um einen benutzerdefinierten System-Heap zu erstellen, verwenden Sie eine Heap-ID im benutzerdefinierten Bereich ( ION_HEAP_CUSTOM_START bis ION_HEAP_CUSTOM_END ), um Zuweisungen durchzuführen.