Modularisation des tas d'ION pour GKI

De nombreux OEM Android modifient le pilote du noyau ION pour diverses raisons, telles que l'ajout de tas de fournisseur et la personnalisation de la gestion du cache (pour plus de détails sur ces modifications, reportez-vous à Intégration de l'allocateur de mémoire ION ). Pour permettre aux OEM de conserver ces modifications lors de l'utilisation de l'image générique du noyau (GKI) , Android Common Kernel v5.4 introduit un cadre pour modulariser les tas ION spécifiques au fournisseur tout en conservant le pilote ION principal intégré. La figure suivante montre la disposition de l'image du noyau. .

Tas d'IONs modulaires

Figure 1. Pilote de noyau ION modularisé

Les tas modulaires ION présentent les avantages suivants.

  • Le pilote principal ION peut faire partie de l'image GKI, permettant à toutes les optimisations de performances et corrections de bogues indépendantes du périphérique d'atteindre tous les appareils.
  • Le pilote principal ION du noyau commun peut gérer l'enregistrement du tas et gérer l'interface avec l'espace utilisateur et les clients du noyau. Les modules de tas du fournisseur sont requis uniquement pour implémenter les opérations de tas personnalisées.
  • Le pilote principal ION (dans le cadre du GKI) peut inclure des hooks pour faciliter le suivi de l'utilisation de la mémoire, ce qui n'était pas possible lorsque chaque OEM disposait de sa propre version du pilote ION.
  • Les tas ION du fournisseur modulaire devraient faciliter toute transition future vers les tas dmabuf .

Exécution

Les modules de tas ION peuvent enregistrer leurs propres opérations dmabuf pour remplacer celles enregistrées par le pilote ION principal. Une opération dmabuf (telle que get_flags() ) qui n'est pas prise en charge par le pilote ION principal renvoie -EOPNOTSUPP si l'implémentation du tas ne dispose pas des remplacements nécessaires.

Pour améliorer les performances, le pilote dmabuf peut effectuer une maintenance partielle du cache (voir changelist ). Les clients du noyau peuvent utiliser les fonctions dma_buf_begin_cpu_access_partial et dma_buf_end_cpu_access_partial pour effectuer une maintenance partielle du cache.

Le noyau commun Android contient des implémentations modulaires du système et des tas d'allocateur de mémoire contigus (CMA) à utiliser comme référence pour la modularisation des tas.

Modifications apportées à l'en-tête ION UAPI

L'en-tête de l'API de l'espace utilisateur ION (UAPI) contient une énumération ion_heap_id à utiliser pour définir une plage d'ID de tas à utiliser par les tas du fournisseur.

 /**
 * 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),
};

De plus, un nouvel IOCTL ( ION_IOC_ABI_VERSION ) peut aider les clients de l'espace utilisateur à déterminer si des tas modulaires sont utilisés.

Remplacement du tas système générique

Le tas du système ION est intégré et fait partie de l'image GKI pour garantir que toute fonctionnalité ayant besoin d'accéder à un tas générique/indépendant du périphérique peut dépendre de son existence. En tant que tel, vous ne pouvez pas remplacer l'ID de tas de ION_HEAP_SYSTEM . Pour créer un tas système personnalisé, utilisez un ID de tas dans la plage personnalisée ( ION_HEAP_CUSTOM_START à ION_HEAP_CUSTOM_END ) pour effectuer des allocations.