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 responsabilité de la plateforme et, par conséquent, ils ne sont pas imputés au budget mémoire du titre. Toutefois, les éléments suivants illustrent les cas où 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
Mise en 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 « fractionnables » de la même manière que l’utilisation de la plateforme et celle du titre sont réparties pour les binaires et les tas. Un mécanisme différent est donc utilisé pour permettre aux développeurs de fournir la mémoire nécessaire de manière déterministe. Le système d’exploitation alloue presque toute la mémoire du noyau qu’il consomme lors 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 habituelles de l’utilisation par 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. Cette valeur est établie de sorte que, lorsque la limite est dépassée, cela résulte directement du comportement du titre plutôt que d’une variation normale du système d’exploitation. La surveillance est mise en œuvre en instrumentant les API suivantes, 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 via XError et le 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() égale à ERROR\_NOT\_ENOUGH\_MEMORY. La sortie de diagnostic est visible dans un débogueur attaché, xbwatson.exe et xbdbgmon.exe.

Avertissement (à 14 Mo)

La sortie suivante s’affiche 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 s’affiche 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).

Tag	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 s’affiche é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 manière similaire 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 événement alloués avec `CreateEvent`.
`File`	Handles de fichiers alloués par `CreateFile`.
`Sema`	Objets sémaphore alloués par `CreateSemaphore`.
`Mmww`	Bitmaps « Write Watch » alloués pour tout `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 suivre les allocations de pages physiques (`XMemAllocatePhysicalPages`, `XMemMapPhysicalPages`) et tous les mappages de fichiers (`CreateFileMapping`, ainsi que 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 (Loose) 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 considérées comme synonymes.

Coûts courants en mémoire du noyau

Le tableau suivant présente les coûts attendus 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 pour 100 000)
Réservations d’adresses virtuelles	80 octets chacune (ou 7,5 Mo pour 100 000)
`XMemAllocatePhysicalPages`	128 octets par page physique de 64 Ko

Augmentation de la limite

L’utilisation de la mémoire des titres de petite taille peut tenir dans les limites existantes. Toutefois, les titres plus volumineux doivent recevoir de la mémoire pour prendre en charge leur utilisation de la mémoire du noyau. L’API XMemTransferMemory permet de fournir la mémoire nécessaire.

Profilage de l’utilisation du pool du noyau

PIX ne prend pas en charge la surveillance de l’utilisation du pool du noyau. Il est possible de surveiller la consommation à l’aide de xperf et de Windows Performance Analyzer (WPA). Suivez les étapes suivantes 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é dans 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 en 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 en 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 en mémoire du noyau

Augmentation de la limite

Profilage de l’utilisation du pool du noyau