Comme Linux semble occuper l'ensemble de la mémoire, notamment avec le
cache, comment savoir quelle est la quantité de mémoire libre pour les
application et mesurer l'activité du swap ?
La finalité, c'est de voir si je peux ajouter des process serveurs
supplémentaires, et augmenter l'espace mémoire pour Oracle.
Jean> Bonjour, Comme Linux semble occuper l'ensemble de la Jean> mémoire, notamment avec le cache, comment savoir quelle est Jean> la quantité de mémoire libre pour les application et mesurer Jean> l'activité du swap ?
Commandes free et top
Fichier /proc/meminfo
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net alias: basile<at>tunes<dot>org 8, rue de la Faïencerie, 92340 Bourg La Reine, France
"Jean" == Jean <jean.veupa@despam.fr> writes:
Jean> Bonjour, Comme Linux semble occuper l'ensemble de la
Jean> mémoire, notamment avec le cache, comment savoir quelle est
Jean> la quantité de mémoire libre pour les application et mesurer
Jean> l'activité du swap ?
Commandes free et top
Fichier /proc/meminfo
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Jean> Bonjour, Comme Linux semble occuper l'ensemble de la Jean> mémoire, notamment avec le cache, comment savoir quelle est Jean> la quantité de mémoire libre pour les application et mesurer Jean> l'activité du swap ?
Commandes free et top
Fichier /proc/meminfo
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net alias: basile<at>tunes<dot>org 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Jérémy JUST
On Tue, 18 Nov 2003 12:34:15 +0100 "Jean" wrote:
Comme Linux semble occuper l'ensemble de la mémoire, notamment avec le cache, comment savoir quelle est la quantité de mémoire libre pour les application et mesurer l'activité du swap ?
Avec `free' et `top', tu auras un bon aperçu.
La finalité, c'est de voir si je peux ajouter des process serveurs supplémentaires, et augmenter l'espace mémoire pour Oracle.
La RAM elle-même est toujours utilisée au maximum. Il ne faut pas s'inquiéter si elle est pleine. Par contre, sur un système bien dimensionné, le swap ne doit pratiquement pas être utilisé.
-- Jérémy JUST
On Tue, 18 Nov 2003 12:34:15 +0100
"Jean" <jean.veupa@despam.fr> wrote:
Comme Linux semble occuper l'ensemble de la mémoire, notamment avec le
cache, comment savoir quelle est la quantité de mémoire libre pour les
application et mesurer l'activité du swap ?
Avec `free' et `top', tu auras un bon aperçu.
La finalité, c'est de voir si je peux ajouter des process serveurs
supplémentaires, et augmenter l'espace mémoire pour Oracle.
La RAM elle-même est toujours utilisée au maximum. Il ne faut pas
s'inquiéter si elle est pleine. Par contre, sur un système bien
dimensionné, le swap ne doit pratiquement pas être utilisé.
Comme Linux semble occuper l'ensemble de la mémoire, notamment avec le cache, comment savoir quelle est la quantité de mémoire libre pour les application et mesurer l'activité du swap ?
Avec `free' et `top', tu auras un bon aperçu.
La finalité, c'est de voir si je peux ajouter des process serveurs supplémentaires, et augmenter l'espace mémoire pour Oracle.
La RAM elle-même est toujours utilisée au maximum. Il ne faut pas s'inquiéter si elle est pleine. Par contre, sur un système bien dimensionné, le swap ne doit pratiquement pas être utilisé.
-- Jérémy JUST
Jean
"Jérémy JUST" a écrit dans le message de news:
Avec `free' et `top', tu auras un bon aperçu.
Oui, mais comme le noyau utilise toute la mémoire, je ne sais pas ce qui est "libre" pour les applications. Voir ci-dessous pour exemple de calcul :
top 2:37pm up 1:46, 2 users, load average: 0.03, 0.05, 0.02
Ça c'est la RAM libre plus les applications. Avec le swap:
Swap: 517 31 486
-- Aurélien DEHAY http://logicielslibres.info
Jean
"Aurélien DEHAY" a écrit dans le message de news:
free -m total used free shared buffers
cached
Mem: 123 113 9 0 11 57
-/+ buffers/cache: 44 78 ^^
Ça c'est la RAM libre plus les applications. Avec le swap:
Swap: 517 31 486
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ? En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soit. Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou. Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de quel seuil ça devient critique ?
Jean
"Aurélien DEHAY" <adehay@nerim.net> a écrit dans le message de
news:87u151x01d.fsf@adehay.net1.nerim.net...
free -m
total used free shared buffers
cached
Mem: 123 113 9 0 11
57
-/+ buffers/cache: 44 78
^^
Ça c'est la RAM libre plus les applications. Avec le swap:
Swap: 517 31 486
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent
seront swappés. Donc l'allocation du swap n'est pas dramatique en soit.
Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou.
Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de
quel seuil ça devient critique ?
Ça c'est la RAM libre plus les applications. Avec le swap:
Swap: 517 31 486
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ? En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soit. Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou. Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de quel seuil ça devient critique ?
Jean
Landry MINOZA
Le Mardi 18 Novembre 2003 15:09, Jean à écrit:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ? En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
le cache permet de différer les accès aux systèmes de fichier afin d'accélérer les temps d'accès aux fichiers par les applications.
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soit. Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou. Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de quel seuil ça devient critique ? avec ton niveau d'exigence, je crois que ce qui s'impose, c'est :
gkrellm-server sur ton serveur et gkrellm sur ta machine d'admin.
Tu verra tout ça graphiquement... Ce sera beaucoup plus explicite. Ensuite, tu compare avec les sorties des progs classiques précités, plus quelques petits tours dans /proc...
-- Landry MINOZA supprimer .invalid pour répondre.
Le Mardi 18 Novembre 2003 15:09, Jean à écrit:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
le cache permet de différer les accès aux systèmes de fichier afin
d'accélérer les temps d'accès aux fichiers par les applications.
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent
seront swappés. Donc l'allocation du swap n'est pas dramatique en soit.
Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou.
Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de
quel seuil ça devient critique ?
avec ton niveau d'exigence, je crois que ce qui s'impose, c'est :
gkrellm-server sur ton serveur et
gkrellm sur ta machine d'admin.
Tu verra tout ça graphiquement...
Ce sera beaucoup plus explicite.
Ensuite, tu compare avec les sorties des progs classiques précités, plus
quelques petits tours dans /proc...
--
Landry MINOZA
supprimer .invalid pour répondre.
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ? En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
le cache permet de différer les accès aux systèmes de fichier afin d'accélérer les temps d'accès aux fichiers par les applications.
2) Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soit. Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou. Comment mesurer l'activité de "swappage" à un instant T ? Et a partir de quel seuil ça devient critique ? avec ton niveau d'exigence, je crois que ce qui s'impose, c'est :
gkrellm-server sur ton serveur et gkrellm sur ta machine d'admin.
Tu verra tout ça graphiquement... Ce sera beaucoup plus explicite. Ensuite, tu compare avec les sorties des progs classiques précités, plus quelques petits tours dans /proc...
-- Landry MINOZA supprimer .invalid pour répondre.
Jérémy JUST
On Tue, 18 Nov 2003 15:09:52 +0100 "Jean" wrote:
Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soi.
En soi, non, tant que ça ne concerne que des processus durablement inactifs.
Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou.
Non, c'est mauvais bien avant. J'ai une machine avec 6 Go de RAM et 16 Go de swap. Récemment, j'ai dû faire un calcul qui chargeait en mémoire 8 Go de données (sachant que la machine était utilisée pour d'autres choses en même temps). Il restait en tout 3 Go de swap disponible. Pourtant mon calcul, ainsi que les autres processus, ont terriblement ramé. Le calcul a pris une semaine, alors qu'il n'a consommé qu'une dizaines d'heures de temps CPU, tout simplement parce qu'il a passé son temps à attendre que les données swappées soient relues depuis le disque.
Le swap doit être considéré comme une solution de secours. Une sorte de vase d'expansion. Son utilisation ralentit tout. Seuls des processus inactifs devraient y être placés. Je crois que sous Linux, `top' donne pas mal de détails par processus. Tu devrais en lire la page de manuel.
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire. Sur une machine inutilisée, tout pourrait être swappé sans aucun inconvénient. Sur une machine sur laquelle tourne Oracle, ce serait très mauvais que les processus oracle soient swappés. J'imagine que certains de ces processus contiennent les index de la base, et ça ferait perdre un temps fou de devoir aller les chercher sur disque.
En pratique, sur une machine personnelle bien configurée (pas de services inutiles), le swap n'est généralement utilisé qu'à hauteur de quelques mégas en temps normal. Pour un serveur, "Ça Dépend"(TM).
-- Jérémy JUST
On Tue, 18 Nov 2003 15:09:52 +0100
"Jean" <jean.veupa@despam.fr> wrote:
Je suppose que l'on peut ajouter des process et que ceux qui
roupillent seront swappés. Donc l'allocation du swap n'est pas
dramatique en soi.
En soi, non, tant que ça ne concerne que des processus durablement
inactifs.
Jusqu'a ce que ça sature et que le system se mette a swapper
comme un fou.
Non, c'est mauvais bien avant.
J'ai une machine avec 6 Go de RAM et 16 Go de swap. Récemment, j'ai dû
faire un calcul qui chargeait en mémoire 8 Go de données (sachant que la
machine était utilisée pour d'autres choses en même temps). Il restait en
tout 3 Go de swap disponible.
Pourtant mon calcul, ainsi que les autres processus, ont terriblement
ramé. Le calcul a pris une semaine, alors qu'il n'a consommé qu'une
dizaines d'heures de temps CPU, tout simplement parce qu'il a passé son
temps à attendre que les données swappées soient relues depuis le disque.
Le swap doit être considéré comme une solution de secours. Une sorte de
vase d'expansion. Son utilisation ralentit tout. Seuls des processus
inactifs devraient y être placés.
Je crois que sous Linux, `top' donne pas mal de détails par processus.
Tu devrais en lire la page de manuel.
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire.
Sur une machine inutilisée, tout pourrait être swappé sans aucun
inconvénient. Sur une machine sur laquelle tourne Oracle, ce serait très
mauvais que les processus oracle soient swappés. J'imagine que certains de
ces processus contiennent les index de la base, et ça ferait perdre un
temps fou de devoir aller les chercher sur disque.
En pratique, sur une machine personnelle bien configurée (pas de
services inutiles), le swap n'est généralement utilisé qu'à hauteur de
quelques mégas en temps normal.
Pour un serveur, "Ça Dépend"(TM).
Je suppose que l'on peut ajouter des process et que ceux qui roupillent seront swappés. Donc l'allocation du swap n'est pas dramatique en soi.
En soi, non, tant que ça ne concerne que des processus durablement inactifs.
Jusqu'a ce que ça sature et que le system se mette a swapper comme un fou.
Non, c'est mauvais bien avant. J'ai une machine avec 6 Go de RAM et 16 Go de swap. Récemment, j'ai dû faire un calcul qui chargeait en mémoire 8 Go de données (sachant que la machine était utilisée pour d'autres choses en même temps). Il restait en tout 3 Go de swap disponible. Pourtant mon calcul, ainsi que les autres processus, ont terriblement ramé. Le calcul a pris une semaine, alors qu'il n'a consommé qu'une dizaines d'heures de temps CPU, tout simplement parce qu'il a passé son temps à attendre que les données swappées soient relues depuis le disque.
Le swap doit être considéré comme une solution de secours. Une sorte de vase d'expansion. Son utilisation ralentit tout. Seuls des processus inactifs devraient y être placés. Je crois que sous Linux, `top' donne pas mal de détails par processus. Tu devrais en lire la page de manuel.
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire. Sur une machine inutilisée, tout pourrait être swappé sans aucun inconvénient. Sur une machine sur laquelle tourne Oracle, ce serait très mauvais que les processus oracle soient swappés. J'imagine que certains de ces processus contiennent les index de la base, et ça ferait perdre un temps fou de devoir aller les chercher sur disque.
En pratique, sur une machine personnelle bien configurée (pas de services inutiles), le swap n'est généralement utilisé qu'à hauteur de quelques mégas en temps normal. Pour un serveur, "Ça Dépend"(TM).
-- Jérémy JUST
Thomas Labourdette
"Aurélien DEHAY" a écrit dans le message de news:
free -m total used free shared buffers
cached
Mem: 123 113 9 0 11 57
-/+ buffers/cache: 44 78 ^^
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
-- Thomas Labourdette 7 semaines : J'ai pensé qu'une bague de ferait plaisir 7 mois : Un vase, c'est toujours utile 7 ans : Tiens, tu t'achèteras ce que tu veux !
"Aurélien DEHAY" <adehay@nerim.net> a écrit dans le message de
news:87u151x01d.fsf@adehay.net1.nerim.net...
free -m
total used free shared buffers
cached
Mem: 123 113 9 0 11
57
-/+ buffers/cache: 44 78
^^
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
--
Thomas Labourdette
7 semaines : J'ai pensé qu'une bague de ferait plaisir
7 mois : Un vase, c'est toujours utile
7 ans : Tiens, tu t'achèteras ce que tu veux !
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
-- Thomas Labourdette 7 semaines : J'ai pensé qu'une bague de ferait plaisir 7 mois : Un vase, c'est toujours utile 7 ans : Tiens, tu t'achèteras ce que tu veux !
J. Mayer
On Tue, 18 Nov 2003 16:01:22 +0100, Jérémy JUST wrote:
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire.
C'est impossible à chiffrer, mais simple à dire: il y a problème quand le programme qui doit prendre la main n'est pas dans la RAM physique ou s'il n'arrive pas à utiliser son timeslice sans être obligé de recharger des données du swap.
Ce qui en clair veut dire: dès que les process actifs commencent à être swappés...
On Tue, 18 Nov 2003 16:01:22 +0100, Jérémy JUST wrote:
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire.
C'est impossible à chiffrer, mais simple à dire:
il y a problème quand le programme qui doit prendre la main
n'est pas dans la RAM physique ou s'il n'arrive pas à utiliser son
timeslice sans être obligé de recharger des données du swap.
Ce qui en clair veut dire: dès que les process actifs commencent
à être swappés...
On Tue, 18 Nov 2003 16:01:22 +0100, Jérémy JUST wrote:
Et a partir de quel seuil ça devient critique ?
C'est impossible à dire.
C'est impossible à chiffrer, mais simple à dire: il y a problème quand le programme qui doit prendre la main n'est pas dans la RAM physique ou s'il n'arrive pas à utiliser son timeslice sans être obligé de recharger des données du swap.
Ce qui en clair veut dire: dès que les process actifs commencent à être swappés...
J. Mayer
On Tue, 18 Nov 2003 18:12:03 +0100, Thomas Labourdette wrote:
"Aurélien DEHAY" a écrit dans le message de news:
free -m total used free shared buffers
cached
Mem: 123 113 9 0 11 57
-/+ buffers/cache: 44 78 ^^
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
Oui, mais non, car les buffers et les caches sont immédiatement (plutot, très rapidement) libérable si une appli a un gros besoin momentanné de mémoire. Ca se paye, bien sur... En fait, sur un système tel que Linux, il n'existe aucun moyen de savoir combien on peut allouer de RAM, et ce, quel que soit le critère proposé. Certains parlent de l'utilisation du swap. Or il est possible de swapper sans même avoir de swap monté ! En effet, les pages de code des programmes sont swappées dans le fichier du programme lui même: pourquoi dupliquer l'information qui existe déjà ? De même, il est possible de gagner des pages sur les buffers et les caches, mais ça peut se payer cruellement en performances. De plus, des pages peuvent se libérer "magiquement": un process fait un retour de fonction, dépile ses arguments et... libère une page qu'il n'a jamais alloué...
La question est: comment fait le kernel ? La réponse est simple: quand on lui demande une page, il ne sait pas s'il peut en trouver une. Des fois, il en a une sous la main de libre. Sinon, il essaye de libérer des pages par tous les moyens. S'il n'y arrive pas, alors seulement à ce moment là, il sait qu'à un instant donné, il n'a plus de RAM dispo, sachant que la même requête pourra réussir une fraction de secondes plus tard (libération implicite d'un gros buffer DMA à la fin d'un transfert disque, par ex).
Donc, le seul moyen de savoir si on peut avoir de la mémoire, c'est de la demander et de s'en servir (les pages réclamées mais jamais utilisées sont comptabilisées dans la taille du process mais ne sont pas allouées physiquement). C'est embêtant, mais c'est la seule bonne réponse...
On Tue, 18 Nov 2003 18:12:03 +0100, Thomas Labourdette wrote:
"Aurélien DEHAY" <adehay@nerim.net> a écrit dans le message de
news:87u151x01d.fsf@adehay.net1.nerim.net...
free -m
total used free shared buffers
cached
Mem: 123 113 9 0 11
57
-/+ buffers/cache: 44 78
^^
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
Oui, mais non, car les buffers et les caches sont immédiatement
(plutot, très rapidement) libérable si une appli a un gros besoin
momentanné de mémoire. Ca se paye, bien sur...
En fait, sur un système tel que Linux, il n'existe aucun moyen
de savoir combien on peut allouer de RAM, et ce, quel que soit le
critère proposé.
Certains parlent de l'utilisation du swap. Or il est possible de
swapper sans même avoir de swap monté ! En effet, les pages de code
des programmes sont swappées dans le fichier du programme lui même:
pourquoi dupliquer l'information qui existe déjà ?
De même, il est possible de gagner des pages sur les buffers et les
caches, mais ça peut se payer cruellement en performances.
De plus, des pages peuvent se libérer "magiquement":
un process fait un retour de fonction, dépile ses arguments et...
libère une page qu'il n'a jamais alloué...
La question est: comment fait le kernel ? La réponse est simple:
quand on lui demande une page, il ne sait pas s'il peut en trouver
une. Des fois, il en a une sous la main de libre. Sinon, il essaye
de libérer des pages par tous les moyens. S'il n'y arrive pas,
alors seulement à ce moment là, il sait qu'à un instant donné,
il n'a plus de RAM dispo, sachant que la même requête pourra réussir
une fraction de secondes plus tard (libération implicite d'un gros
buffer DMA à la fin d'un transfert disque, par ex).
Donc, le seul moyen de savoir si on peut avoir de la mémoire,
c'est de la demander et de s'en servir (les pages réclamées mais
jamais utilisées sont comptabilisées dans la taille du process
mais ne sont pas allouées physiquement). C'est embêtant, mais
c'est la seule bonne réponse...
On Tue, 18 Nov 2003 18:12:03 +0100, Thomas Labourdette wrote:
"Aurélien DEHAY" a écrit dans le message de news:
free -m total used free shared buffers
cached
Mem: 123 113 9 0 11 57
-/+ buffers/cache: 44 78 ^^
Ça c'est la RAM libre plus les applications. Avec le swap:
1) Désolé mais c'est pas clair. Dans l'exemple il me reste combien ?
En fait, je ne sais pas ce que sont ces 2 zones : "Buffers" et "Cache" ...
78Mo (used - (free+buffer+cache))
Oui, mais non, car les buffers et les caches sont immédiatement (plutot, très rapidement) libérable si une appli a un gros besoin momentanné de mémoire. Ca se paye, bien sur... En fait, sur un système tel que Linux, il n'existe aucun moyen de savoir combien on peut allouer de RAM, et ce, quel que soit le critère proposé. Certains parlent de l'utilisation du swap. Or il est possible de swapper sans même avoir de swap monté ! En effet, les pages de code des programmes sont swappées dans le fichier du programme lui même: pourquoi dupliquer l'information qui existe déjà ? De même, il est possible de gagner des pages sur les buffers et les caches, mais ça peut se payer cruellement en performances. De plus, des pages peuvent se libérer "magiquement": un process fait un retour de fonction, dépile ses arguments et... libère une page qu'il n'a jamais alloué...
La question est: comment fait le kernel ? La réponse est simple: quand on lui demande une page, il ne sait pas s'il peut en trouver une. Des fois, il en a une sous la main de libre. Sinon, il essaye de libérer des pages par tous les moyens. S'il n'y arrive pas, alors seulement à ce moment là, il sait qu'à un instant donné, il n'a plus de RAM dispo, sachant que la même requête pourra réussir une fraction de secondes plus tard (libération implicite d'un gros buffer DMA à la fin d'un transfert disque, par ex).
Donc, le seul moyen de savoir si on peut avoir de la mémoire, c'est de la demander et de s'en servir (les pages réclamées mais jamais utilisées sont comptabilisées dans la taille du process mais ne sont pas allouées physiquement). C'est embêtant, mais c'est la seule bonne réponse...
