Utilisation de la mémoire du noyau

Dans Windows et dans le Microsoft Game Development Kit (GDK), la mémoire du noyau existe sous la forme d’un pool unique partagé par le noyau et tous les pilotes. La mémoire du noyau est toujours allouée à partir de la partition système. La majorité des besoins en mémoire du noyau relèvent de la plateforme et, par conséquent, ils ne sont pas imputés au budget de mémoire du titre. Toutefois, les éléments suivants montrent dans quels cas le code du jeu est directement responsable de l’utilisation de la mémoire du noyau.

Structures de suivi pour chaque réservation de mémoire virtuelle
Gestion des fichiers, des événements et des objets de synchronisation de threads
Réseau

Les titres doivent fournir la mémoire nécessaire à l’utilisation du noyau dont ils sont directement responsables. Comme la mémoire du noyau existe sous la forme d’un pool unique, les allocations ne sont pas « divisibles » de la même façon que l’utilisation de la plateforme et celle du titre sont divisées pour les binaires et les tas. Un mécanisme différent est plutôt utilisé pour permettre aux développeurs de fournir la mémoire nécessaire de façon déterministe. Le système d’exploitation alloue presque toute la mémoire du noyau qu’il consomme dans le cadre de la séquence de démarrage du système d’exploitation du Microsoft Game Development Kit (GDK). Une fois le démarrage terminé, les variations typiques de l’utilisation de la plateforme sont d’environ 1 à 2 Mo. Lorsqu’un processus de titre est lancé, la consommation actuelle de mémoire du noyau est interrogée et un « seuil de bruit » est établi à 16 Mo au-dessus de la consommation actuelle de mémoire du noyau. La valeur est établie de sorte que, lorsque la limite est dépassée, cela résulte directement du comportement du titre plutôt que de la variation normale du système d’exploitation. La surveillance est mise en œuvre en instrumentant les API suivantes, qui sont connues pour entraîner des allocations de mémoire du noyau.

CreateFile
CreateEvent
CreateSemaphore

Si un appel à l’une de ces API se produit alors que l’utilisation de la mémoire du noyau approche du seuil ou l’a dépassé, des informations supplémentaires sont fournies par l’intermédiaire de XError et du flux de débogage. Si l’utilisation de la mémoire du noyau a dépassé la limite, l’appel d’API échoue avec une valeur GetLastError() de ERROR\_NOT\_ENOUGH\_MEMORY. La sortie de diagnostic peut être consultée dans un débogueur attaché, xbwatson.exe et xbdbgmon.exe.

Avertissement (à 14 Mo)

La sortie suivante apparaît lorsqu’un avertissement se déclenche à 14 Mo.

XERROR: HR:8007000E threadID:1096 WARNING: Title is consuming significant kernel pool memory. 
Use XMemGetWorkingSetStatistics to review usage and XMemTransferMemory to raise the quota.

Erreur (à 16 Mo)

La sortie suivante apparaît lorsqu’une erreur se déclenche à 16 Mo.

\[XMEM\]: Initial Kernel Pool Usage: 19628032  
\[XMEM\]: Current Kernel Pool Usage: 36683776  
\[XMEM\]: Kernel Pool Limit: 36405248
  
Top Consumers:

Le tableau suivant présente le format des balises de pool (Pool Tag).

Balise	PagedAllocs	PagedFrees	PagedUsed	NonPagedAllocs	NonPagedFrees	NonPagedUsed
Even	0	0	0	238750	219461	2469856
Thre	0	0	0	385	130	620160
Mdl	0	0	0	3843	3079	740080
MmRe	318	159	693520	0	0	0
MmSt	563	132	6133760	0	0	0
File	185	2	1096096	0	0	0
TcDM	0	0	0	1078	681	1587104
AfdB	0	0	0	86	35	1623152
Mmww	0	0	0	5503	705	530272
Xvnc	0	0	0	13	6	1448784
XFSd	0	0	0	1473	927	537040
Sema	0	0	0	12766	150	1615552

L’erreur suivante apparaît également.

XERROR: HR:8007000E threadID:1164 ERROR: Title has exhausted kernel pool
quota. Common consumers include handles, thread sync. objects, and
virtual address reservations. Use XMemTransferMemory to raise the quota.

Toutes les allocations de mémoire du noyau sont associées à une balise (de façon semblable au balisage avec XMEM\_MAKE\_TAG et XMemVirtualAlloc) pour indiquer l’utilisation de la mémoire. La balise peut aider à déterminer la source de l’utilisation de la mémoire. Le tableau suivant présente les balises de « forte utilisation » les plus courantes liées à l’utilisation par le titre.

Balise	Objectif
`Even`	Objets d’événement alloués avec `CreateEvent`.
`File`	Handles de fichiers alloués par `CreateFile`.
`Sema`	Objets sémaphores alloués par `CreateSemaphore`.
`Mmww`	Bitmaps « Write Watch » alloués pour toute réservation `MEM\_RESERVE` de mémoire graphique afin de prendre en charge les captures GPU de Performance Investigator for XBOX (PIX).
`MmSt`, `Mdl`	Structures de contrôle utilisées par le MM pour assurer le suivi des allocations de pages physiques (`XMemAllocatePhysicalPages`, `XMemMapPhysicalPages`) et de tous les mappages de fichiers (`CreateFileMapping`, ainsi que de tous les fichiers .dll ou .exe chargés.
`XFSk`, `XFsm`	Mémoire utilisée par XRFS, le pilote de système de fichiers Win32 utilisé pour les déploiements de fichiers libres et les scénarios d’exécution à partir du PC (Run-from-PC).
`TcDM`, `AfdB`	Mémoire utilisée par le pilote réseau.

La mémoire du noyau est divisée en deux grandes catégories appelées « non paginée » et « paginée ». Dans le Microsoft Game Development Kit (GDK), il n’existe aucune différence fonctionnelle entre ces catégories, et elles peuvent être traitées comme synonymes.

Coûts courants de la mémoire du noyau

Le tableau suivant présente les coûts prévus en mémoire du noyau de chaque action répertoriée.

Action	Coût
Ouverture d’un fichier	Environ 2 Ko par handle de fichier
Événements et sémaphores	128 octets par événement ou sémaphore (ou 12 Mo par 100 000)
Réservations d’adresses virtuelles	80 octets chacune (ou 7,5 Mo par 100 000)
`XMemAllocatePhysicalPages`	128 octets par page physique de 64 Ko

Augmentation de la limite

Les titres de plus petite taille peuvent avoir une utilisation de la mémoire qui respecte les limites existantes. Toutefois, les titres de plus grande taille doivent recevoir de la mémoire pour prendre en charge leur utilisation de la mémoire du noyau. L’API XMemTransferMemory est utilisée pour fournir la mémoire nécessaire.

Profilage de l’utilisation du pool du noyau

La prise en charge de la surveillance de l’utilisation du pool du noyau n’est pas disponible dans PIX. Il est possible de surveiller la consommation à l’aide de xperf et de Windows Performance Analyzer (WPA). Suivez les étapes ci-dessous pour profiler la mémoire du noyau.

Entrez la commande xbrun /x/title xperf -start -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree -f d:\krnl.etl
Exécutez le scénario du titre.
Entrez la commande xbrun /x/title xperf -stop -d d:\krnl.merged.etl
Entrez la commande xbcp xd:\krnl.merged.etl %TEMP%\pool_usage.etl
Ouvrez le fichier pool_usage.etl dans WPA et effectuez l’analyse comme illustré à la figure 1.

Figure 1. Analyse du pool de mémoire du noyau dans WPA.

Introduction

Onboarding & Access

Setup & Install

Build Your First Title

Avertissement (à 14 Mo)

Erreur (à 16 Mo)

Coûts courants de la mémoire du noyau

Augmentation de la limite

Profilage de l’utilisation du pool du noyau

​Avertissement (à 14 Mo)

​Erreur (à 16 Mo)

​Coûts courants de la mémoire du noyau

​Augmentation de la limite

​Profilage de l’utilisation du pool du noyau

Avertissement (à 14 Mo)

Erreur (à 16 Mo)

Coûts courants de la mémoire du noyau

Augmentation de la limite

Profilage de l’utilisation du pool du noyau