Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
------------------------> La Vie Est Belle <----------------------<<<
Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
------------------------> La Vie Est Belle <----------------------<<<
Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
------------------------> La Vie Est Belle <----------------------<<<
Gilbert OLIVIER wrote:
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
mais d'ou vient ce block de 4K ? qu'est ce qu'il contient ? si n'est pas
dans la ram et pas dans le swap, ou donc sont stocker ses données ? et
quelle interet de chercher un block virtuel qui ne contient rien
finalement ?
------------------------> La Vie Est Belle <----------------------<<<
Gilbert OLIVIER <gilbert.olivier@orange.fr> wrote:
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
mais d'ou vient ce block de 4K ? qu'est ce qu'il contient ? si n'est pas
dans la ram et pas dans le swap, ou donc sont stocker ses données ? et
quelle interet de chercher un block virtuel qui ne contient rien
finalement ?
------------------------> La Vie Est Belle <----------------------<<<
Gilbert OLIVIER wrote:
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
mais d'ou vient ce block de 4K ? qu'est ce qu'il contient ? si n'est pas
dans la ram et pas dans le swap, ou donc sont stocker ses données ? et
quelle interet de chercher un block virtuel qui ne contient rien
finalement ?
------------------------> La Vie Est Belle <----------------------<<<
Je pensai qu'il y avait un rapport avec le nombre de frameworks utilisés
par l'appli et des "avidités" de chacun de ceux-ci. De toute façon elle
est virtuelle donc ...
Juste à noter qu'avec Mavericks il n'est plus possible d'afficher dans
le moniteur d'activité la mémoire virtuelle par application. On a juste
droit à une valeur globale.
Je pensai qu'il y avait un rapport avec le nombre de frameworks utilisés
par l'appli et des "avidités" de chacun de ceux-ci. De toute façon elle
est virtuelle donc ...
Juste à noter qu'avec Mavericks il n'est plus possible d'afficher dans
le moniteur d'activité la mémoire virtuelle par application. On a juste
droit à une valeur globale.
Je pensai qu'il y avait un rapport avec le nombre de frameworks utilisés
par l'appli et des "avidités" de chacun de ceux-ci. De toute façon elle
est virtuelle donc ...
Juste à noter qu'avec Mavericks il n'est plus possible d'afficher dans
le moniteur d'activité la mémoire virtuelle par application. On a juste
droit à une valeur globale.
pehache wrote:
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
Le premier paragraphe de "About Virtual memory":
"Virtual memory allows an operating system to escape the limitations of
physical RAM. The virtual memory manager creates a logical address space
(or "virtual" address space) for each process and divides it up into
uniformly-sized chunks of memory called pages. The processor and its
memory management unit (MMU) maintain a page table to map pages in the
program's logical address space to hardware addresses in the computer's
RAM. When a program's code accesses an address in memory, the MMU uses
the page table to translate the specified logical address into the
actual hardware memory address. This translation occurs automatically
and is transparent to the running application."
Me semble pourtant très clair et suffisant.
Et en français, ce qui est virtuel n'est pas physique.
Donc on a une mémoire virtuelle donc de la taille necessaire aux besoin s
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
pehache <pehache.7@gmail.com> wrote:
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
Le premier paragraphe de "About Virtual memory":
"Virtual memory allows an operating system to escape the limitations of
physical RAM. The virtual memory manager creates a logical address space
(or "virtual" address space) for each process and divides it up into
uniformly-sized chunks of memory called pages. The processor and its
memory management unit (MMU) maintain a page table to map pages in the
program's logical address space to hardware addresses in the computer's
RAM. When a program's code accesses an address in memory, the MMU uses
the page table to translate the specified logical address into the
actual hardware memory address. This translation occurs automatically
and is transparent to the running application."
Me semble pourtant très clair et suffisant.
Et en français, ce qui est virtuel n'est pas physique.
Donc on a une mémoire virtuelle donc de la taille necessaire aux besoin s
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
pehache wrote:
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
Le premier paragraphe de "About Virtual memory":
"Virtual memory allows an operating system to escape the limitations of
physical RAM. The virtual memory manager creates a logical address space
(or "virtual" address space) for each process and divides it up into
uniformly-sized chunks of memory called pages. The processor and its
memory management unit (MMU) maintain a page table to map pages in the
program's logical address space to hardware addresses in the computer's
RAM. When a program's code accesses an address in memory, the MMU uses
the page table to translate the specified logical address into the
actual hardware memory address. This translation occurs automatically
and is transparent to the running application."
Me semble pourtant très clair et suffisant.
Et en français, ce qui est virtuel n'est pas physique.
Donc on a une mémoire virtuelle donc de la taille necessaire aux besoin s
de "l'appli" indépendamment de la taille mémoire physique. Quand
"l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
mémoire physique, le système transfère dans la ram le bloc de 4k la
contenant.
> Ce n'est pas parce que la VM n'occupe pas forcément d'espace physique
> que les valeurs n'ont aucun sens. Ce ne sont pas juste des nombres
> aléatoires, ils doivent avoir des explications et correspondre à de s
> allocations réellement présentes dans le code.
La totalité de ces addressages dépend des allocations requises par le s
processus.
Tu peux t'amuser (bon courage en passant) à visualiser les régions de la
mémoire virtuelle allouées à des processus avec vmmap(1).
Cependant je maintiens que savoir, pour un utilisateur lambda, pourquoi
l'application iApp.app a demandé à avoir X Mo dans la mémoire virtu elle,
ne sert strictement à rien.
> Oui d'accord, mais le mélange constant entre le concept de mémoire
> virtuelle et celui de swap n'aide pas vraiment un "béotien" à compr endre.
Que tu mélanges l'enchaînement des évènements c'est un fait
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
T'as vraiment un problème avec la définition des mots toi.
Parce que les allocations faites par les processus dans la mémoire
virtuelle sont *virtuelles*. Elles deviennent physique uniquement
lorsque celles-ci sont écrites dans la mémoire physique (la RAM) ou d ans
le « backing store » (le swap).
> Encore une fois j'avais lu, et encore une fois toutes ces explications
> tournent exclusivement autour du mécanisme de swap. Quelqu'un qui lit ça
> NE PEUT PAS comprendre comment il peut y avoir 200Go de mémoire
> virtuelle annoncée, avec 4Go de RAM et 128Go de disque.
Bon là je ne peux plus rien.
> Ce n'est pas parce que la VM n'occupe pas forcément d'espace physique
> que les valeurs n'ont aucun sens. Ce ne sont pas juste des nombres
> aléatoires, ils doivent avoir des explications et correspondre à de s
> allocations réellement présentes dans le code.
La totalité de ces addressages dépend des allocations requises par le s
processus.
Tu peux t'amuser (bon courage en passant) à visualiser les régions de la
mémoire virtuelle allouées à des processus avec vmmap(1).
Cependant je maintiens que savoir, pour un utilisateur lambda, pourquoi
l'application iApp.app a demandé à avoir X Mo dans la mémoire virtu elle,
ne sert strictement à rien.
> Oui d'accord, mais le mélange constant entre le concept de mémoire
> virtuelle et celui de swap n'aide pas vraiment un "béotien" à compr endre.
Que tu mélanges l'enchaînement des évènements c'est un fait
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
T'as vraiment un problème avec la définition des mots toi.
Parce que les allocations faites par les processus dans la mémoire
virtuelle sont *virtuelles*. Elles deviennent physique uniquement
lorsque celles-ci sont écrites dans la mémoire physique (la RAM) ou d ans
le « backing store » (le swap).
> Encore une fois j'avais lu, et encore une fois toutes ces explications
> tournent exclusivement autour du mécanisme de swap. Quelqu'un qui lit ça
> NE PEUT PAS comprendre comment il peut y avoir 200Go de mémoire
> virtuelle annoncée, avec 4Go de RAM et 128Go de disque.
Bon là je ne peux plus rien.
> Ce n'est pas parce que la VM n'occupe pas forcément d'espace physique
> que les valeurs n'ont aucun sens. Ce ne sont pas juste des nombres
> aléatoires, ils doivent avoir des explications et correspondre à de s
> allocations réellement présentes dans le code.
La totalité de ces addressages dépend des allocations requises par le s
processus.
Tu peux t'amuser (bon courage en passant) à visualiser les régions de la
mémoire virtuelle allouées à des processus avec vmmap(1).
Cependant je maintiens que savoir, pour un utilisateur lambda, pourquoi
l'application iApp.app a demandé à avoir X Mo dans la mémoire virtu elle,
ne sert strictement à rien.
> Oui d'accord, mais le mélange constant entre le concept de mémoire
> virtuelle et celui de swap n'aide pas vraiment un "béotien" à compr endre.
Que tu mélanges l'enchaînement des évènements c'est un fait
> Non, personnellement j'ai compris, sauf que l'explication donnée par
> Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est dit
> nulle part qu'une page de mémoire virtuelle n'est pas forcément
> connectée à une page de mémoire physique. Or c'est un point presq ue
> central pour la compréhension du truc.
T'as vraiment un problème avec la définition des mots toi.
Parce que les allocations faites par les processus dans la mémoire
virtuelle sont *virtuelles*. Elles deviennent physique uniquement
lorsque celles-ci sont écrites dans la mémoire physique (la RAM) ou d ans
le « backing store » (le swap).
> Encore une fois j'avais lu, et encore une fois toutes ces explications
> tournent exclusivement autour du mécanisme de swap. Quelqu'un qui lit ça
> NE PEUT PAS comprendre comment il peut y avoir 200Go de mémoire
> virtuelle annoncée, avec 4Go de RAM et 128Go de disque.
Bon là je ne peux plus rien.
C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
chaque process (dans les 2 Go).
C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
chaque process (dans les 2 Go).
C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
chaque process (dans les 2 Go).
Le mercredi 29 janvier 2014 10:00:23 UTC+1, Patrick Stadelmann a écrit :
>
>
> C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
> chaque process (dans les 2 Go).
>
Et sais-tu pourquoi faire ?
Le mercredi 29 janvier 2014 10:00:23 UTC+1, Patrick Stadelmann a écrit :
>
>
> C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
> chaque process (dans les 2 Go).
>
Et sais-tu pourquoi faire ?
Le mercredi 29 janvier 2014 10:00:23 UTC+1, Patrick Stadelmann a écrit :
>
>
> C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
> chaque process (dans les 2 Go).
>
Et sais-tu pourquoi faire ?
est ce que j'ai compris ?
est ce que j'ai compris ?
est ce que j'ai compris ?
En 10.6 non plus, ce que l'on peut afficher c'est l'équivalent de VPRVT
(espace d'adressage privé) dans "top", et pas VSIZE (espace d'adressage
total). Or c'est VSIZE qui est utilisé pour calculer la valeur dont il
est question ici.
En 10.6 non plus, ce que l'on peut afficher c'est l'équivalent de VPRVT
(espace d'adressage privé) dans "top", et pas VSIZE (espace d'adressage
total). Or c'est VSIZE qui est utilisé pour calculer la valeur dont il
est question ici.
En 10.6 non plus, ce que l'on peut afficher c'est l'équivalent de VPRVT
(espace d'adressage privé) dans "top", et pas VSIZE (espace d'adressage
total). Or c'est VSIZE qui est utilisé pour calculer la valeur dont il
est question ici.
Le mercredi 29 janvier 2014 09:36:17 UTC+1, Gilbert OLIVIER a écrit :
> pehache wrote:
>
> > Non, personnellement j'ai compris, sauf que l'explication donnée par
> > Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est
> > dit nulle part qu'une page de mémoire virtuelle n'est pas forcément
> > connectée à une page de mémoire physique. Or c'est un point presque
> > central pour la compréhension du truc.
>
> Le premier paragraphe de "About Virtual memory":
>
> "Virtual memory allows an operating system to escape the limitations of
> physical RAM. The virtual memory manager creates a logical address space
> (or "virtual" address space) for each process and divides it up into
> uniformly-sized chunks of memory called pages. The processor and its
> memory management unit (MMU) maintain a page table to map pages in the
> program's logical address space to hardware addresses in the computer's
> RAM. When a program's code accesses an address in memory, the MMU uses
> the page table to translate the specified logical address into the
> actual hardware memory address. This translation occurs automatically
> and is transparent to the running application."
>
> Me semble pourtant très clair et suffisant.
Non, c'est une explication du processus de swap, mais qui sous-entend que
le contenu d'une page de mémoire virtuelle est forcément défini et
présent soit en RAM soit sur le disque.
Ca ne dit pas du tout qu'une page de mémoire virtuelle peut n'avoir aucun
contenu défini et donc n'être présente physiquement nulle part.
>
> Et en français, ce qui est virtuel n'est pas physique.
>
Il y a plusieurs sens à "virtuel", et plus encore de la façon dont on
l'utilise aujourd'hui. On dit une machine "virtuelle" (genre VMWare),
mais elle a bien un support physique qui est une vraie machine...
Dans le cas de la mémoire "virtuelle", elle l'est de plusieurs façons
différentes : 1) par une couche d'abstraction découplant les adresses en
mémoire virtuelle des adresses physiques (RAM ou disque), et 2) par le
fait que certaines pages de la mémoire virtuelle n'ont aucune adresse
physique (ni en RAM ni sur disque). Mais le 2) ne découle pas forcément
du 1), et si il n'est pas précisé ce n'est pas une évidence du tout. Le
1) seul suffirait à qualifier le truc de "virtuel".
>
>
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
>
...ou pas si c'est une page qui n'a aucune existence physique, pas même
sur le disque : si un process veut lire une telle page, je suppose que
le kernel lui renvoie tout simplement des zéros sans rien transférer en
RAM.
Je zappe le reste, qui ne fait que ré-expliquer le processus de swap
Le mercredi 29 janvier 2014 09:36:17 UTC+1, Gilbert OLIVIER a écrit :
> pehache <pehache.7@gmail.com> wrote:
>
> > Non, personnellement j'ai compris, sauf que l'explication donnée par
> > Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est
> > dit nulle part qu'une page de mémoire virtuelle n'est pas forcément
> > connectée à une page de mémoire physique. Or c'est un point presque
> > central pour la compréhension du truc.
>
> Le premier paragraphe de "About Virtual memory":
>
> "Virtual memory allows an operating system to escape the limitations of
> physical RAM. The virtual memory manager creates a logical address space
> (or "virtual" address space) for each process and divides it up into
> uniformly-sized chunks of memory called pages. The processor and its
> memory management unit (MMU) maintain a page table to map pages in the
> program's logical address space to hardware addresses in the computer's
> RAM. When a program's code accesses an address in memory, the MMU uses
> the page table to translate the specified logical address into the
> actual hardware memory address. This translation occurs automatically
> and is transparent to the running application."
>
> Me semble pourtant très clair et suffisant.
Non, c'est une explication du processus de swap, mais qui sous-entend que
le contenu d'une page de mémoire virtuelle est forcément défini et
présent soit en RAM soit sur le disque.
Ca ne dit pas du tout qu'une page de mémoire virtuelle peut n'avoir aucun
contenu défini et donc n'être présente physiquement nulle part.
>
> Et en français, ce qui est virtuel n'est pas physique.
>
Il y a plusieurs sens à "virtuel", et plus encore de la façon dont on
l'utilise aujourd'hui. On dit une machine "virtuelle" (genre VMWare),
mais elle a bien un support physique qui est une vraie machine...
Dans le cas de la mémoire "virtuelle", elle l'est de plusieurs façons
différentes : 1) par une couche d'abstraction découplant les adresses en
mémoire virtuelle des adresses physiques (RAM ou disque), et 2) par le
fait que certaines pages de la mémoire virtuelle n'ont aucune adresse
physique (ni en RAM ni sur disque). Mais le 2) ne découle pas forcément
du 1), et si il n'est pas précisé ce n'est pas une évidence du tout. Le
1) seul suffirait à qualifier le truc de "virtuel".
>
>
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
>
...ou pas si c'est une page qui n'a aucune existence physique, pas même
sur le disque : si un process veut lire une telle page, je suppose que
le kernel lui renvoie tout simplement des zéros sans rien transférer en
RAM.
Je zappe le reste, qui ne fait que ré-expliquer le processus de swap
Le mercredi 29 janvier 2014 09:36:17 UTC+1, Gilbert OLIVIER a écrit :
> pehache wrote:
>
> > Non, personnellement j'ai compris, sauf que l'explication donnée par
> > Apple (et c'est pareil ailleurs) est très (trop) partielle. Il n'est
> > dit nulle part qu'une page de mémoire virtuelle n'est pas forcément
> > connectée à une page de mémoire physique. Or c'est un point presque
> > central pour la compréhension du truc.
>
> Le premier paragraphe de "About Virtual memory":
>
> "Virtual memory allows an operating system to escape the limitations of
> physical RAM. The virtual memory manager creates a logical address space
> (or "virtual" address space) for each process and divides it up into
> uniformly-sized chunks of memory called pages. The processor and its
> memory management unit (MMU) maintain a page table to map pages in the
> program's logical address space to hardware addresses in the computer's
> RAM. When a program's code accesses an address in memory, the MMU uses
> the page table to translate the specified logical address into the
> actual hardware memory address. This translation occurs automatically
> and is transparent to the running application."
>
> Me semble pourtant très clair et suffisant.
Non, c'est une explication du processus de swap, mais qui sous-entend que
le contenu d'une page de mémoire virtuelle est forcément défini et
présent soit en RAM soit sur le disque.
Ca ne dit pas du tout qu'une page de mémoire virtuelle peut n'avoir aucun
contenu défini et donc n'être présente physiquement nulle part.
>
> Et en français, ce qui est virtuel n'est pas physique.
>
Il y a plusieurs sens à "virtuel", et plus encore de la façon dont on
l'utilise aujourd'hui. On dit une machine "virtuelle" (genre VMWare),
mais elle a bien un support physique qui est une vraie machine...
Dans le cas de la mémoire "virtuelle", elle l'est de plusieurs façons
différentes : 1) par une couche d'abstraction découplant les adresses en
mémoire virtuelle des adresses physiques (RAM ou disque), et 2) par le
fait que certaines pages de la mémoire virtuelle n'ont aucune adresse
physique (ni en RAM ni sur disque). Mais le 2) ne découle pas forcément
du 1), et si il n'est pas précisé ce n'est pas une évidence du tout. Le
1) seul suffirait à qualifier le truc de "virtuel".
>
>
> Donc on a une mémoire virtuelle donc de la taille necessaire aux besoins
> de "l'appli" indépendamment de la taille mémoire physique. Quand
> "l'appli" veut accéder à une adresse, si celle-ci n'est pas dans la
> mémoire physique, le système transfère dans la ram le bloc de 4k la
> contenant.
>
...ou pas si c'est une page qui n'a aucune existence physique, pas même
sur le disque : si un process veut lire une telle page, je suppose que
le kernel lui renvoie tout simplement des zéros sans rien transférer en
RAM.
Je zappe le reste, qui ne fait que ré-expliquer le processus de swap