Paramètres du ratio d'overcommit pour Android (Kernal Adiutor)

Les applications n'utilisent pas toujours autant de mémoire que ce qu'elles demandent, donc le système dira à l'application qu'elle a une quantité X de mémoire vive à utiliser alors qu'en réalité seulement Y de mémoire vive a été mise de côté et X>Y est essentiellement le ratio. Ainsi, 50% signifierait que le système essaierait de mettre de côté 50% de mémoire physique en moins pour cette application qu'il ne le souhaite, mais il garde le secret pour l'application et utilise le multitâche pour essayer de lui donner la RAM dont elle a besoin.

La modification de l'overcommit_ratio est, comme la plupart des ajustements Android, un mythe d'optimisation. Si vous faites des recherches sur ces paramètres du noyau, vous découvrirez que l'option overcommit_ratio détermine uniquement l'overcommit autorisé lorsque le mode overcommit manuel est activé, c'est-à-dire overcommit_memory=2. Aucun appareil Android n'a ce paramètre à ma connaissance, et les deux appareils que j'ai essayé d'activer ce mode ont tous deux entraîné des échecs de malloc/fork à l'échelle du système, quel que soit le ratio précédemment défini.

Il est décevant qu'un bon développeur comme celui ou ceux qui sont derrière Kernel Adiutor n'aient même pas pris la peine de faire des recherches à ce sujet.

S'engager à l'excès est bon et nécessaire. Les applications alloueront toujours plus de mémoire qu'elles n'en utilisent réellement, comme on peut le voir dans les divergences vss/rss/pss. Il semble que les seuls modes valables pour le surengagement de la mémoire dans Android sont soit de déterminer heuristiquement la limite du surengagement (i.e. overcommit_memory=0) qui est la valeur par défaut de Linux, soit de toujours réussir les engagements qui ne sont pas absurdes et de laisser les gestionnaires LMK/OOM tuer les choses si nécessaire (i.e. overcommit_memory=1) qui je pense est la valeur par défaut d'Android (bien que la documentation dise le contraire).

En bref, la valeur que vous définissez n'a pas d'importance car elle ne fait littéralement rien pour les distributions Android typiques (peut-être même toutes). Toute amélioration de performance perçue est un placebo.

EDIT : Il semble que overcommit_memory=0 ne devrait être utilisé que sur les systèmes qui ont une partition swap dédiée pour agir comme un filet de sécurité aux crashs OOM lorsque la mémoire est réellement pleine, mais cette configuration n'est pas idéale pour Android - LMK d'Android gère les situations de faible mémoire sans avoir besoin de pagination du disque.