2009-05-12 2 views
5

Comment puis-je connaître la taille de la table de pages d'un processus Linux, ainsi que toute autre comptabilité de processus de taille variable?Comment trouver ou calculer la taille d'une table de page d'un processus Linux et la comptabilité d'un autre noyau?

+0

Je ne suis pas sûr de comprendre votre question: La taille de la page, AFAIK, n'est pas dépendante du processus sur la même plate-forme (eh bien, je peux me tromper, je ne suis pas un gourou linux ..). Btw je me demande: voulez-vous vraiment dire page * table * taille? Ou voulez-vous dire plutôt la taille de la page *, comme il est plus souvent nécessaire par les programmeurs à mon humble avis? –

+0

Je veux dire la quantité de mémoire (kernel) que les tables de pages d'un processus particulier consomment. –

Répondre

1

Vous n'êtes pas sûr de Linux, mais la plupart des variantes UNIX fournissent sysctl(3) à cette fin. Il y a aussi l'utilitaire de ligne de commande sysctl(8).

+0

Qu'est-ce que Unix vous permet de lire la pagetablesize (par opposition à la mise en page) via sysctl? – eckes

5

Si vous êtes vraiment intéressé par les tables de pages, faites une

$ cat /proc/meminfo | grep PageTables 
PageTables:  24496 kB 
+1

Ceci est utile, mais j'ai besoin de savoir si cette taille est "trop ​​grande". S'il y a une limite à cette taille, cela provoquerait l'échec de fork() et la proximité de cette limite avec le noyau. Idéalement, j'aurais aussi besoin de savoir quelle portion de la taille de PageTables est utilisée par un processus spécifique, de sorte que lorsque fork() essaie de copier les tables pour ce processus, la limite serait dépassée. –

1

Hmmm, de retour à Ye Olden Tymes, nous appelions nlist (3) pour obtenir l'adresse du système pour les données que nous étions intéressés dans, puis ouvrez/dev/kmem, recherchez l'adresse, puis lisez les données. Je ne sais pas si cela fonctionne sous Linux, mais il pourrait être utile de taper "man 3 nlist" et de voir ce qui revient.

1

Vous devez décrire votre problème et ne pas demander de détails. Si vous fourrez trop (en particulier avec un processus qui a un grand espace d'adressage) il y a toutes sortes de choses qui vont mal (y compris hors de la mémoire), frapper une taille maximale pagetable est à mon humble avis pas un problème réaliste. Thad a dit, je serais également intéressé de lire un partage de pagetable de processus dans Linux. En règle générale, on peut cependant supposer que chaque processus occulte un partage dans le pagetable qui est égal à sa taille virtuelle, par exemple 6 octets pour chaque page. Ainsi, par exemple, si vous avez une base de données Oracle avec 8 Go de SGA et 500 processus le partageant, chacun des processus utilisera 14 Mo pagetable, ce qui entraîne 7 Go pagetables + 8 Go SGA. (numéros d'échantillons de http://kevinclosson.wordpress.com/2009/07/25/little-things-doth-crabby-make-%E2%80%93-part-ix-sometimes-you-have-to-really-really-want-your-hugepages/)

+0

Oh BTW, quelques chiffres avec d'énormes pages maintenant: http://kevinclosson.wordpress.com/2009/07/28/quantifying-hugepages-memory-savings-with-oracle-database-11g/ – eckes

7

Depuis Linux 2.6.10, la quantité de mémoire utilisée par les tables de pages d'un seul processus a été exposée via le champ VmPTE de /proc/<pid>/status.

+0

Il semble bien fonctionner , sauf quand j'alloue des pages énormes avec mmap: la taille rapportée est une petite constante, quelle que soit la taille de l'allocation (noyau 4.4.0-77). –

+0

La valeur rapportée par le champ VmPMD semble correcte, elle croît linéairement avec la taille de l'allocation, même avec des pages énormes. Mais je ne pense pas que cela rende compte de toute la table des pages (l'homme dit "Taille des tables de pages de second niveau"). Lors de l'expérimentation avec des pages classiques, cette valeur est environ 500 fois inférieure à VmPTE. –

Questions connexes