Couche d'abstraction de cgroup

Android 10 et versions ultérieures utilisent une couche d'abstraction de groupe de contrôle (cgroup) avec des profils de tâches, que les développeurs peuvent utiliser pour décrire un ou plusieurs ensembles de restrictions à appliquer à un thread ou à un processus. Le système suit ensuite les actions prescrites des profils de tâches pour sélectionner un ou plusieurs cgroups appropriés, via lesquels les restrictions sont appliquées, et les modifications apportées à l'ensemble de caractéristiques cgroup sous-jacent peuvent être effectuées sans affecter les couches logicielles supérieures.

À propos des cgroups

Les cgroups fournissent un mécanisme permettant d'agréger et de partitionner des ensembles de tâches (qui se composent de processus, de threads et de tous leurs futurs enfants) en groupes hiérarchiques avec un comportement spécialisé. Android utilise des cgroups pour contrôler et comptabiliser les ressources système telles que l'utilisation et l'allocation du processeur et de la mémoire, avec la prise en charge des cgroups v1 et v2 du noyau Linux.

Android 9 et versions antérieures

Dans Android 9 et versions antérieures, le script d'initialisation init.rc contenait l'ensemble des cgroups disponibles, leurs points d'installation et leurs versions. Bien que ces éléments puissent être modifiés, le framework Android s'attendait à ce qu'un ensemble spécifique de cgroups existe à des emplacements spécifiques avec une version et une hiérarchie de sous-groupes spécifiques, en fonction du script. Cela limitait la possibilité de choisir la prochaine version de cgroup à utiliser ou de modifier la hiérarchie de cgroup pour utiliser de nouvelles fonctionnalités.

Android 10 et versions ultérieures

Android 10 et versions ultérieures utilisent des cgroups avec des profils de tâches :

• Configuration des cgroups. Les développeurs décrivent la configuration des cgroups dans leur fichier cgroups.json pour définir des ensembles de cgroups, ainsi que leurs emplacements d'installation et leurs attributs. Tous les cgroups sont installés lors de la phase d'initialisation précoce du processus d'initialisation.
• Profils de tâches. Ils fournissent une abstraction qui dissocie la fonctionnalité requise des détails de son implémentation. Le framework Android applique les profils de tâches comme décrit dans le fichier task_profiles.json à un processus ou à un thread à l'aide des API SetTaskProfiles et SetProcessProfiles. (Ces API sont propres à Android 11 et versions ultérieures.)

Pour assurer la rétrocompatibilité, les fonctions héritées set_cpuset_policy, set_sched_policy et get_sched_policy fournissent la même API et la même fonctionnalité, mais leur implémentation a été modifiée pour utiliser des profils de tâches. Pour les nouveaux cas d'utilisation, AOSP recommande d'utiliser les nouvelles API de profils de tâches au lieu de la fonction héritée set_sched_policy.

Fichier de description des cgroups

Les cgroups sont décrits dans le cgroups.json fichier situé sous <ANDROID_BUILD_TOP>/system/core/libprocessgroup/profiles/. Chaque contrôleur est décrit dans une sous-section et doit comporter au minimum les éléments suivants :

• Nom, défini par le champ Controller.
• Chemin d'installation, défini par le champ Path.
• Mode, UID (ID utilisateur) et GID (ID de groupe) décrivant le propriétaire et les modes d'accès pour les fichiers sous ce chemin d'accès (tous facultatifs).
• Attribut Optional, défini sur true pour permettre au système d'ignorer l'erreur d'installation causée par un contrôleur cgroup que le noyau ne prend pas en charge.

Exemple de fichier cgroups.json

L'exemple ci-dessous présente des descriptions pour les contrôleurs cgroup v1 (Cgroups) et cgroup v2 (Cgroups2) avec leurs chemins d'accès respectifs.

{
  "Cgroups": [
    {
      "Controller": "cpu",
      "Path": "/dev/cpuctl",
      "Mode": "0755",
      "UID": "system",
      "GID": "system"
    },
    {
      "Controller": "memory",
      "Path": "/dev/memcg",
      "Mode": "0700",
      "Optional": true
    }
  ],
 "Cgroups2": {
   "Path": "/sys/fs/cgroup",
   "Mode": "0755",
   "UID": "system",
   "GID": "system",
   "Controllers": [
     {
       "Controller": "freezer",
       "Path": ".",
       "Mode": "0755",
       "UID": "system",
       "GID": "system"
     }
   ]
 }
}

Cet exemple de fichier contient deux sections : Cgroups (décrivant les contrôleurs cgroup v1) et Cgroups2 (décrivant les contrôleurs cgroup v2). Tous les contrôleurs de la hiérarchie cgroups v2 sont installés au même emplacement. Par conséquent, la section Cgroups2 possède ses propres attributs Path, Mode, UID et GID pour décrire l'emplacement et les attributs de la racine de la hiérarchie. L'attribut Path pour Controllers sous Cgroups2 est relatif à ce chemin d'accès racine. Dans Android 12 et versions ultérieures, vous pouvez définir un contrôleur cgroup spécifié avec le chemin d'accès et le mode comme "Optional" en le définissant sur true.

Le fichier cgroups.json est analysé dans le cadre du processus d'initialisation, lors de la phase d'initialisation précoce, et les cgroups sont installés aux emplacements spécifiés. Pour obtenir ultérieurement les emplacements d'installation des cgroups, utilisez la fonction d'API CgroupGetControllerPath.

Fichier de profils de tâches

Le task_profiles.json fichier se trouve sous <ANDROID_BUILD_TOP>/system/core/libprocessgroup/profiles/. Utilisez-le pour décrire un ensemble spécifique d'actions à appliquer à un processus ou à un thread. Un ensemble d'actions est associé à un nom de profil, qui est utilisé dans les appels SetTaskProfiles et SetProcessProfiles pour appeler des actions de profil.

Exemple de fichier task_profiles.json

{
  "Attributes": [
    {
      "Name": "MemSoftLimit",
      "Controller": "memory",
      "File": "memory.soft_limit_in_bytes"
    },
    {
      "Name": "MemSwappiness",
      "Controller": "memory",
      "File": "memory.swappiness"
    }
  ],
  "Profiles": [
    {
      "Name": "MaxPerformance",
      "Actions" : [
        {
          "Name" : "JoinCgroup",
          "Params" :
          {
            "Controller": "schedtune",
            "Path": "top-app"
          }
        }
      ]
    },
    {
      "Name": "TimerSlackHigh",
      "Actions" : [
        {
          "Name" : "SetTimerSlack",
          "Params" :
          {
            "Slack": "40000000"
          }
        }
      ]
    },
    {
      "Name": "LowMemoryUsage",
      "Actions" : [
        {
          "Name" : "SetAttribute",
          "Params" :
          {
            "Name" : "MemSoftLimit",
            "Value" : "16MB"
          }
        },
        {
          "Name" : "SetAttribute",
          "Params" :
          {
            "Name" : "MemSwappiness",
            "Value" : "150"

          }
        }
      ]
    }
  ]
  "AggregateProfiles": [
     {
       "Name": "SCHED_SP_DEFAULT",
       "Profiles": [ "TimerSlackHigh", "MaxPerformance" ]
     },
     {
       "Name": "SCHED_SP_BACKGROUND",
       "Profiles": [ "LowMemoryUsage" ]
     }
}

Attribuez des noms à des fichiers cgroup spécifiques en tant qu'entrées dans votre liste Attributes. Chaque entrée contient les éléments suivants :

• Le champ Name spécifie le nom de l'attribut.
• Le champ Controller fait référence à un contrôleur cgroup du fichier cgroups.json, par son nom.
• Le champ File nomme un fichier spécifique sous ce contrôleur.

Les attributs sont des références dans les définitions de profils de tâches. En dehors des profils de tâches, utilisez-les uniquement lorsque le framework nécessite un accès direct à ces fichiers et que l'accès ne peut pas être abstrait à l'aide de profils de tâches. Dans tous les autres cas, utilisez des profils de tâches. Ils offrent un meilleur découplage entre le comportement requis et les détails de son implémentation.

La section Profiles contient des définitions de profils de tâches avec les éléments suivants :

• Le champ Name définit le nom du profil.

• La section Actions répertorie un ensemble d'actions effectuées lorsque le profil est appliqué. Chaque action comporte les éléments suivants :

  • Le champ Name spécifie l'action.
  • La section Params spécifie un ensemble de paramètres pour l'action.

Les actions compatibles sont répertoriées dans le tableau :

Android 12 et versions ultérieures comportent une section AggregateProfiles qui contient des profils agrégés, chacun étant un alias pour un ensemble d'un ou plusieurs profils. Les définitions de profils agrégés se composent des éléments suivants :

• Le champ Name spécifie le nom du profil agrégé.
• Le champ Profiles répertorie les noms des profils inclus dans le profil agrégé.

Lorsqu'un profil agrégé est appliqué, tous les profils qu'il contient sont également appliqués automatiquement. Les profils agrégés peuvent contenir des profils individuels ou d'autres profils agrégés, à condition qu'il n'y ait pas de récursions (un profil qui s'inclut lui-même).

Commande de langage d'initialisation task_profiles

Une commande task_profiles dans le langage d'initialisation Android est disponible pour Android 12 et versions ultérieures afin de faciliter l'activation des profils de tâches pour un processus spécifique. Elle remplace la commande writepid (obsolète dans Android 12) qui était utilisée pour migrer un processus entre des cgroups. La commande task_profiles offre la possibilité de modifier les implémentations sous-jacentes sans affecter les couches supérieures. Dans l'exemple ci-dessous, ces deux commandes effectuent la même opération :

• writepid /dev/cpuctl/top-app/tasks

  Obsolète dans Android 12, cette commande était utilisée pour écrire le PID de la tâche actuelle dans le fichier /dev/cpuctl/top-app/tasks.

• task_profiles MaxPerformance

  Joint le processus actuel au groupe d'applications principales sous le contrôleur "cpu" (cpuctl), ce qui entraîne l'écriture du PID du processus dans dev/cpuctl/top-app/tasks.

Utilisez toujours la commande task_profiles pour migrer des tâches dans des hiérarchies de cgroups dans Android 12 et versions ultérieures. Elle accepte un ou plusieurs paramètres, représentant les noms des profils spécifiés dans le fichier task_profiles.json.

Profils de tâches par niveau d'API

Dans Android 12 et versions ultérieures, vous pouvez modifier ou remplacer des définitions dans les fichiers cgroups.json et task_profiles.json par défaut, soit en basant votre modification sur le niveau d'API Android, soit en l'effectuant à partir de la partition du fournisseur.

Pour remplacer les définitions en fonction du niveau d'API, les fichiers suivants doivent être présents sur l'appareil :

• /system/etc/task_profiles/cgroups_<API level>.json

  Utilisez ce fichier pour les cgroups spécifiques à un niveau d'API.

• /system/etc/task_profiles/task_profiles_<API level>.json

  Utilisez ce fichier pour les profils spécifiques à un niveau d'API.

Pour remplacer les définitions de la partition du fournisseur, les fichiers suivants doivent être présents sur l'appareil :

• /vendor/etc/cgroups.json
• /vendor/etc/task_profiles.json

Si un attribut ou une définition de profil dans ces fichiers utilise le même nom que dans le fichier par défaut, la définition de fichier (au niveau de l'API ou du fournisseur) remplace la définition précédente. Notez également que les définitions au niveau du fournisseur remplacent les définitions au niveau de l'API. Si la nouvelle définition porte un nouveau nom, l'ensemble d'attributs ou de profils est modifié avec la nouvelle définition.

Le système Android charge les fichiers cgroup et task_profile dans cet ordre :

1. Fichiers cgroups.json et task_profiles.json par défaut.
2. Fichiers spécifiques au niveau de l'API, le cas échéant.
3. Fichiers de partition du fournisseur, le cas échéant.

Modifications apportées à l'API existante

Android 10 et versions ultérieures conservent les fonctions set_cpuset_policy, set_sched_policy et get_sched_policy sans modification de l'API. Toutefois, Android 10 déplace ces fonctions dans libprocessgroup, qui contient désormais toutes les fonctionnalités liées aux cgroups.

Bien que l'en-tête cutils/sched_policy.h existe toujours, pour éviter de casser le code existant, assurez-vous que le nouveau code inclut un nouvel en-tête processgroup/sched_policy.h à la place.

Les modules qui utilisent l'une de ces fonctions doivent ajouter une dépendance à la bibliothèque libprocessgroup dans leur fichier makefile. Si un module n'utilise aucune autre fonctionnalité libcutils, supprimez la dépendance de la bibliothèque libcutils du fichier makefile.

API de profils de tâches

Les API privées de processgroup/processgroup.h sont définies dans le tableau :