Taille Mémoire Virtuel : 243,62 Go!

Matt

28/01/2014 à 13:51

On Mar 28 janvier 2014 (00:50),
pehache wrote:

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/>

Lien mort

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.
Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

--
“Bad programmers have all the answers. Good testers have all the questions.”
– Gil Zilberfeld

On Mar 28 janvier 2014 (00:50),
pehache <pehache.7@gmail.com> wrote:

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/>

Lien mort

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.
Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

--
“Bad programmers have all the answers. Good testers have all the questions.”
– Gil Zilberfeld

Vous avez filtré cet utilisateur ! Consultez son message

On Mar 28 janvier 2014 (00:50),
pehache wrote:

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/>

Lien mort

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.
Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

--
“Bad programmers have all the answers. Good testers have all the questions.”
– Gil Zilberfeld

Matt

28/01/2014 à 14:11

On Mar 28 janvier 2014 (12:07),
pehache wrote:

La compréhension que j'avais de la mémoire virtuelle était la suivante :

La mémoire virtuelle est à la base définie au niveau de chaque process
: c'est l'espace d'adressage logique et continu d'un process. Chaque
process a sa propre mémoire virtuelle et par défaut ne peut accéder à
celle d'un autre process (*).

La mémoire virtuelle d'un process est découpée en pages (de 4ko sur OS
X). Chaque page est physiquement présente en RAM ou sur le disque, et
le kernel maintient une table de correspondance entre les pages de la
mémoire virtuelle et les pages "physiques", ce qui permet aux process
d'y accéder de manière transparente pour eux.

La mémoire "résidente" d'un process, c'est sa quantité de mémoire
virtuelle physiquement présente en RAM.

Oui mais uniquement pour les processus qui ne sont pas créés par des
applications/frameworks userland.
La mémoire résidente (normalement appelée « Wired memory ») ne contient
que des pages qui ne peuvent être stockées dans le « backing store » (le
swap, ndlr).

(*) 2 pages de mémoire virtuelle de 2 process différents peuvent
pointer vers la même page de mémoire physique : c'est typiquement le
cas pour les librairies partagées, utilisées par définition par
plusieurs process (exemple la libc). Elles sont physiquement présentes
une seule fois en mémoire et apparaissent dans la mémoire virtuelle de
plusieurs process. Ainsi, la somme des mémoires virtuelles de
plusieurs process est en général supérieure à la mémoire physique
réellement occupée par ces mêmes process.

Oui ça c'est le fonctionnement que l'on observe et sur Mac OS X et sur
les autres Unix avec un kernel monolithique disons-le, traditionnel.

Et ce dont je n'étais pas sûr, mais que j'ai vérifié par un petit test
aujourd'hui : une page de mémoire virtuelle peut ne pointer vers
aucune page physique. Par exemple quand un process alloue de la
mémoire, mais ne l'utilise pas tout de suite. Cela explique aussi que
la mémoire virtuelle totale (la somme de tous les process) soit
souvent nettement supérieure à la taille de la RAM + du swap.

Tout à fait. C'est le rôle premier de la mémoire virtuelle Mach.
De pouvoir adresser - dans un espace logique - plus de mémoire supposée
que de mémoire physiquement présente.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous
Linux. Et qui ne correspondent d'ailleurs pas aux pratiques courantes
de programmation : les process utilisent généralement la majorité de
la mémoire qu'ils allouent (en tous cas depuis que l'allocation
dynamique existe !)...

Les valeurs de la mémoire virtuelle n'ont aucun sens, encore une fois...

--
“Knock, knock.” “Who’s there?” very long pause…. “Java.” – Anonymous

On Mar 28 janvier 2014 (12:07),
pehache <pehache.7@gmail.com> wrote:

La compréhension que j'avais de la mémoire virtuelle était la suivante :

La mémoire virtuelle est à la base définie au niveau de chaque process
: c'est l'espace d'adressage logique et continu d'un process. Chaque
process a sa propre mémoire virtuelle et par défaut ne peut accéder à
celle d'un autre process (*).

La mémoire virtuelle d'un process est découpée en pages (de 4ko sur OS
X). Chaque page est physiquement présente en RAM ou sur le disque, et
le kernel maintient une table de correspondance entre les pages de la
mémoire virtuelle et les pages "physiques", ce qui permet aux process
d'y accéder de manière transparente pour eux.

La mémoire "résidente" d'un process, c'est sa quantité de mémoire
virtuelle physiquement présente en RAM.

Oui mais uniquement pour les processus qui ne sont pas créés par des
applications/frameworks userland.
La mémoire résidente (normalement appelée « Wired memory ») ne contient
que des pages qui ne peuvent être stockées dans le « backing store » (le
swap, ndlr).

(*) 2 pages de mémoire virtuelle de 2 process différents peuvent
pointer vers la même page de mémoire physique : c'est typiquement le
cas pour les librairies partagées, utilisées par définition par
plusieurs process (exemple la libc). Elles sont physiquement présentes
une seule fois en mémoire et apparaissent dans la mémoire virtuelle de
plusieurs process. Ainsi, la somme des mémoires virtuelles de
plusieurs process est en général supérieure à la mémoire physique
réellement occupée par ces mêmes process.

Oui ça c'est le fonctionnement que l'on observe et sur Mac OS X et sur
les autres Unix avec un kernel monolithique disons-le, traditionnel.

Et ce dont je n'étais pas sûr, mais que j'ai vérifié par un petit test
aujourd'hui : une page de mémoire virtuelle peut ne pointer vers
aucune page physique. Par exemple quand un process alloue de la
mémoire, mais ne l'utilise pas tout de suite. Cela explique aussi que
la mémoire virtuelle totale (la somme de tous les process) soit
souvent nettement supérieure à la taille de la RAM + du swap.

Tout à fait. C'est le rôle premier de la mémoire virtuelle Mach.
De pouvoir adresser - dans un espace logique - plus de mémoire supposée
que de mémoire physiquement présente.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous
Linux. Et qui ne correspondent d'ailleurs pas aux pratiques courantes
de programmation : les process utilisent généralement la majorité de
la mémoire qu'ils allouent (en tous cas depuis que l'allocation
dynamique existe !)...

Les valeurs de la mémoire virtuelle n'ont aucun sens, encore une fois...

--
“Knock, knock.” “Who’s there?” very long pause…. “Java.” – Anonymous

Vous avez filtré cet utilisateur ! Consultez son message

On Mar 28 janvier 2014 (12:07),
pehache wrote:

La compréhension que j'avais de la mémoire virtuelle était la suivante :

La mémoire virtuelle est à la base définie au niveau de chaque process
: c'est l'espace d'adressage logique et continu d'un process. Chaque
process a sa propre mémoire virtuelle et par défaut ne peut accéder à
celle d'un autre process (*).

La mémoire virtuelle d'un process est découpée en pages (de 4ko sur OS
X). Chaque page est physiquement présente en RAM ou sur le disque, et
le kernel maintient une table de correspondance entre les pages de la
mémoire virtuelle et les pages "physiques", ce qui permet aux process
d'y accéder de manière transparente pour eux.

La mémoire "résidente" d'un process, c'est sa quantité de mémoire
virtuelle physiquement présente en RAM.

Oui mais uniquement pour les processus qui ne sont pas créés par des
applications/frameworks userland.
La mémoire résidente (normalement appelée « Wired memory ») ne contient
que des pages qui ne peuvent être stockées dans le « backing store » (le
swap, ndlr).

(*) 2 pages de mémoire virtuelle de 2 process différents peuvent
pointer vers la même page de mémoire physique : c'est typiquement le
cas pour les librairies partagées, utilisées par définition par
plusieurs process (exemple la libc). Elles sont physiquement présentes
une seule fois en mémoire et apparaissent dans la mémoire virtuelle de
plusieurs process. Ainsi, la somme des mémoires virtuelles de
plusieurs process est en général supérieure à la mémoire physique
réellement occupée par ces mêmes process.

Oui ça c'est le fonctionnement que l'on observe et sur Mac OS X et sur
les autres Unix avec un kernel monolithique disons-le, traditionnel.

Et ce dont je n'étais pas sûr, mais que j'ai vérifié par un petit test
aujourd'hui : une page de mémoire virtuelle peut ne pointer vers
aucune page physique. Par exemple quand un process alloue de la
mémoire, mais ne l'utilise pas tout de suite. Cela explique aussi que
la mémoire virtuelle totale (la somme de tous les process) soit
souvent nettement supérieure à la taille de la RAM + du swap.

Tout à fait. C'est le rôle premier de la mémoire virtuelle Mach.
De pouvoir adresser - dans un espace logique - plus de mémoire supposée
que de mémoire physiquement présente.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous
Linux. Et qui ne correspondent d'ailleurs pas aux pratiques courantes
de programmation : les process utilisent généralement la majorité de
la mémoire qu'ils allouent (en tous cas depuis que l'allocation
dynamique existe !)...

Les valeurs de la mémoire virtuelle n'ont aucun sens, encore une fois...

--
“Knock, knock.” “Who’s there?” very long pause…. “Java.” – Anonymous

pehache

28/01/2014 à 21:54

Le 28/01/2014 13:26, Gilles Aurejac a écrit :

Par exemple quand un process alloue de la mémoire, mais ne
l'utilise pas tout de suite.

Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
pour te donner un exemple :
Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
(contrairement à d'anciens système où c'étaient juste des descriptions
vectorielles).
C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.

Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
(sans compter les effets). ça ne devient de la mémoire physique que si
la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

A son lancement (et selon le framework de programmation utilisé : coccoa
ou carbon) une application OS X s'attribue plein de fenêtres pour
accélérer leur affichage ensuite.

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

Cela explique aussi que la mémoire virtuelle
totale (la somme de tous les process) soit souvent nettement supérieure à
la taille de la RAM + du swap.

Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
qui ne correspondent d'ailleurs pas aux pratiques courantes de
programmation : les process utilisent généralement la majorité de la
mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
existe !)...

Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...

Et justement, concernant 10.9 une de ses nouvelles fonction est
justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

Le 28/01/2014 13:26, Gilles Aurejac a écrit :

Par exemple quand un process alloue de la mémoire, mais ne
l'utilise pas tout de suite.

Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
pour te donner un exemple :
Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
(contrairement à d'anciens système où c'étaient juste des descriptions
vectorielles).
C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.

Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
(sans compter les effets). ça ne devient de la mémoire physique que si
la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

A son lancement (et selon le framework de programmation utilisé : coccoa
ou carbon) une application OS X s'attribue plein de fenêtres pour
accélérer leur affichage ensuite.

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

Cela explique aussi que la mémoire virtuelle
totale (la somme de tous les process) soit souvent nettement supérieure à
la taille de la RAM + du swap.

Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
qui ne correspondent d'ailleurs pas aux pratiques courantes de
programmation : les process utilisent généralement la majorité de la
mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
existe !)...

Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...

Et justement, concernant 10.9 une de ses nouvelles fonction est
justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

Vous avez filtré cet utilisateur ! Consultez son message

Le 28/01/2014 13:26, Gilles Aurejac a écrit :

Par exemple quand un process alloue de la mémoire, mais ne
l'utilise pas tout de suite.

Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
pour te donner un exemple :
Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
(contrairement à d'anciens système où c'étaient juste des descriptions
vectorielles).
C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.

Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
(sans compter les effets). ça ne devient de la mémoire physique que si
la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

A son lancement (et selon le framework de programmation utilisé : coccoa
ou carbon) une application OS X s'attribue plein de fenêtres pour
accélérer leur affichage ensuite.

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

Cela explique aussi que la mémoire virtuelle
totale (la somme de tous les process) soit souvent nettement supérieure à
la taille de la RAM + du swap.

Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
qui ne correspondent d'ailleurs pas aux pratiques courantes de
programmation : les process utilisent généralement la majorité de la
mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
existe !)...

Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...

Et justement, concernant 10.9 une de ses nouvelles fonction est
justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

eric.hamery

28/01/2014 à 22:17

pehache wrote:

Le 28/01/2014 13:26, Gilles Aurejac a écrit :
>
>> Par exemple quand un process alloue de la mémoire, mais ne
>> l'utilise pas tout de suite.
>
> Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
> pour te donner un exemple :
> Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
> qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
> (contrairement à d'anciens système où c'étaient juste des descriptions
> vectorielles).
> C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
> sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
> Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.
>
> Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
> (sans compter les effets). ça ne devient de la mémoire physique que si
> la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

>
> A son lancement (et selon le framework de programmation utilisé : coccoa
> ou carbon) une application OS X s'attribue plein de fenêtres pour
> accélérer leur affichage ensuite.
>

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

>
>> Cela explique aussi que la mémoire virtuelle
>> totale (la somme de tous les process) soit souvent nettement supérieure à
>> la taille de la RAM + du swap.
>
> Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

>
>> Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
>> rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
>> qui ne correspondent d'ailleurs pas aux pratiques courantes de
>> programmation : les process utilisent généralement la majorité de la
>> mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
>> existe !)...
>
> Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...
>
> Et justement, concernant 10.9 une de ses nouvelles fonction est
> justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

ouai je suis asser d'accore avec toi, c'est pas clair...

infos a part... sous mavericks 20Go de memoire virtuel apres 14 jours
d'utilisation de l'ordi sans redemarage...

--
/ Mes Services - http://www.metamaitre.com
--o-- Forum "Méta-Science" - http://d.pr/VUA6
/ <08-D<X=8 - http://dieupurre.free.fr/DieuPurRe/Bienvenue.html

------------------------> La Vie Est Belle <----------------------<<<

pehache <pehache.7@gmail.com> wrote:

Le 28/01/2014 13:26, Gilles Aurejac a écrit :
>
>> Par exemple quand un process alloue de la mémoire, mais ne
>> l'utilise pas tout de suite.
>
> Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
> pour te donner un exemple :
> Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
> qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
> (contrairement à d'anciens système où c'étaient juste des descriptions
> vectorielles).
> C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
> sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
> Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.
>
> Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
> (sans compter les effets). ça ne devient de la mémoire physique que si
> la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

>
> A son lancement (et selon le framework de programmation utilisé : coccoa
> ou carbon) une application OS X s'attribue plein de fenêtres pour
> accélérer leur affichage ensuite.
>

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

>
>> Cela explique aussi que la mémoire virtuelle
>> totale (la somme de tous les process) soit souvent nettement supérieure à
>> la taille de la RAM + du swap.
>
> Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

>
>> Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
>> rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
>> qui ne correspondent d'ailleurs pas aux pratiques courantes de
>> programmation : les process utilisent généralement la majorité de la
>> mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
>> existe !)...
>
> Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...
>
> Et justement, concernant 10.9 une de ses nouvelles fonction est
> justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

ouai je suis asser d'accore avec toi, c'est pas clair...

infos a part... sous mavericks 20Go de memoire virtuel apres 14 jours
d'utilisation de l'ordi sans redemarage...

--
/ Mes Services - http://www.metamaitre.com
--o-- Forum "Méta-Science" - http://d.pr/VUA6
/ <08-D<X=8 - http://dieupurre.free.fr/DieuPurRe/Bienvenue.html

------------------------> La Vie Est Belle <----------------------<<<

Vous avez filtré cet utilisateur ! Consultez son message

pehache wrote:

Le 28/01/2014 13:26, Gilles Aurejac a écrit :
>
>> Par exemple quand un process alloue de la mémoire, mais ne
>> l'utilise pas tout de suite.
>
> Je ne suis pas développeur donc pas sûr à 100% de ce que je dis mais
> pour te donner un exemple :
> Sous MacOS X, chaque fenêtre se voit allouer un espace en mémoire vive
> qui, si tu veux une analogie, est une image "bitmap" de cette fenêtre
> (contrairement à d'anciens système où c'étaient juste des descriptions
> vectorielles).
> C'est d'ailleurs pour ça que les connexions bureau à distance étaient et
> sont encore beaucoup plus rapides sous windows (TSE, citrix) que sous
> Mac OS X : l'affichage est entièrement "bitmap", pas vectoriel.
>
> Basiquement, 1 fenêtre de 800x600 pixels = 1,4 Mo de mémoire virtuelle
> (sans compter les effets). ça ne devient de la mémoire physique que si
> la fenêtre est réellement visible à l'écran.

Mouais... et quand elle est cachée la mémoire est libérée ? Elle est
alors recalculée entièrement si elle redevient visible ?

>
> A son lancement (et selon le framework de programmation utilisé : coccoa
> ou carbon) une application OS X s'attribue plein de fenêtres pour
> accélérer leur affichage ensuite.
>

Simplement préallouer la mémoire ne fait à priori pas gagner beaucoup de
temps si ce qu'il y a dedans n'est pas précalculé. Ou alors je ne
comprends pas bien ce que tu veux dire.

>
>> Cela explique aussi que la mémoire virtuelle
>> totale (la somme de tous les process) soit souvent nettement supérieure à
>> la taille de la RAM + du swap.
>
> Le swap n'a vraiment *rien à voir* avec la mémoire virtuelle, sous OS X.

Oui, mais explique ça à Apple (et à tous les autres) qui n'a de cesse de
parler du swap dès que le sujet de la mémoire virtuelle est abordé.

>
>> Mais, j'insiste, ça n'explique toujours pas les valeurs extrêmes
>> rencontrées sous 10.6, et qu'on ne retrouve ni sous 10.9 ni sous Linux. Et
>> qui ne correspondent d'ailleurs pas aux pratiques courantes de
>> programmation : les process utilisent généralement la majorité de la
>> mémoire qu'ils allouent (en tous cas depuis que l'allocation dynamique
>> existe !)...
>
> Non, cf plus haut.

Mouais encore... Pas convaincu. Ca ne représente que quelques Mo par
fenêtre, donc pour arriver à une centaine de Go il en faudrait des
fenêtres...
>
> Et justement, concernant 10.9 une de ses nouvelles fonction est
> justement la compression mémoire :

Oui, mais c'est le contenu de la mémoire physique qui est compressé, ce
qui ne devrait pas impacter du tout la mémoire virtuelle, qui reste un
espace d'adressage logique.

ouai je suis asser d'accore avec toi, c'est pas clair...

infos a part... sous mavericks 20Go de memoire virtuel apres 14 jours
d'utilisation de l'ordi sans redemarage...

--
/ Mes Services - http://www.metamaitre.com
--o-- Forum "Méta-Science" - http://d.pr/VUA6
/ <08-D<X=8 - http://dieupurre.free.fr/DieuPurRe/Bienvenue.html

------------------------> La Vie Est Belle <----------------------<<<

eric.hamery

28/01/2014 à 22:43

Dieu PurRê Méta-Maitre de l'Extrême wrote:

infos a part... sous mavericks 20Go de memoire virtuel apres 14 jours
d'utilisation de l'ordi sans redemarage...

et sur le protable macbook 5 minute apres le demarage, 232 Go de mémoire
virtuel...

--
/ Mes Services - http://www.metamaitre.com
--o-- Forum "Méta-Science" - http://d.pr/VUA6
/ <08-D<X=8 - http://dieupurre.free.fr/DieuPurRe/Bienvenue.html

------------------------> La Vie Est Belle <----------------------<<<

pehache

29/01/2014 à 07:19

Le 28/01/2014 13:51, Matt a écrit :

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

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 à des
allocations réellement présentes dans le code.

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

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" à comprendre.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.

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.

Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

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.

Le 28/01/2014 13:51, Matt a écrit :

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

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 à des
allocations réellement présentes dans le code.

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

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" à comprendre.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.

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.

Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

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.

Vous avez filtré cet utilisateur ! Consultez son message

Le 28/01/2014 13:51, Matt a écrit :

<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/About/About.html>

J'avais déjà lu cette page. Mais en réalité elle n'explique pas les
valeurs énormes souvent rapportées dans 10.6.

Elle n'explique pas les valeurs car cela n'a pas de sens. Cela reste
virtuel (cet espace n'occupe aucun espace physique, que ce soit dans la
RAM ou sur le disque).

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 à des
allocations réellement présentes dans le code.

Et comme tous les articles qui traitent de la mémoire virtuelle, il
rentre tout de suite dans les histoires de swap :

"To give processes access to their entire 4 gigabyte or 18 exabyte
address space, OS X uses the hard disk to hold data that is not
currently in use. As memory gets full, sections of memory that are not
being used are written to disk to make room for data that is needed now.
The portion of the disk that stores the unused data is known as the
backing store because it provides the backup storage for main memory."

Car l'usage d'un « backing store » est requis si et seulement si il n'y
a pas assez de place en RAM.

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" à comprendre.

et tout le long c'est comme ça... Et on arrive à la conclusion que la
mémoire virtuelle d'un process est physiquement en RAM et sur le disque,
et on ne comprend pas pourquoi la mémoire virtuelle totale annoncée dans
10.6 dépasse toujours TRES largement la taille de la RAM + la taille du
fichier de swap.

Si tu en conclus cela, c'est que tu n'as pas compris.

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.

Lis ce qui suit (pardonnes-moi mais j'ai vraiment la flemme de traduire
ces paragraphes) :

« 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.

As far as a program is concerned, addresses in its logical address space
are always available. However, if an application accesses an address on
a memory page that is not currently in physical RAM, a page fault
occurs. When that happens, the virtual memory system invokes a special
page-fault handler to respond to the fault immediately. The page-fault
handler stops the currently executing code, locates a free page of
physical memory, loads the page containing the needed data from disk,
updates the page table, and then returns control to the program’s code,
which can then access the memory address normally. This process is known
as paging.

If there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or “swapping out”); moving data from the backing
store back in to physical memory is called paging in (or “swapping in”).
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed.

In both OS X and iOS, the size of a page is 4 kilobytes. Thus, every
time a page fault occurs, the system reads 4 kilobytes from disk. Disk
thrashing can occur when the system spends a disproportionate amount of
time handling page faults and reading and writing pages, rather than
executing code for a program.

Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than reading
directly from RAM. If the system has to write a page to disk before it
can read another page from disk, the performance impact is even worse. »

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.

gilbert.olivier

29/01/2014 à 09:36

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.
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 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.

Maintenant, c'est sur que l'on va à la longue remplir la RAM. Le 3ème
paragraphe donne la solution employée:

"if there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or "swapping out"); moving data from the backing
store back in to physical memory is called paging in (or "swapping in").
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed."

On fait de la place en transférant un(des) bloc(s) de 4k sur le disque
dur et on vient d'introduire le swapping qui est donc complémentaire au
processus de mémoire virtuelle.

Tu noteras que l'on à:
De la mémoire virtuelle (qui n'existe pas physiquement)
et
De la mémoire physique qui elle est bien réelle et limitée: RAM et
fichiers de swap sur le disque dur

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.

Ben si.

Maintenant savoir pourquoi tant de mémoire virtuelle, je pense que ce
n'est pas explicable "comme çà" il faudrait être beaucoup plus intime
avec les algos et le code du sytème mais ce n'est pas physiquement à
notre portée ni de notre niveau (enfin pas du miens).

--
Gilbert

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.
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 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.

Maintenant, c'est sur que l'on va à la longue remplir la RAM. Le 3ème
paragraphe donne la solution employée:

"if there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or "swapping out"); moving data from the backing
store back in to physical memory is called paging in (or "swapping in").
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed."

On fait de la place en transférant un(des) bloc(s) de 4k sur le disque
dur et on vient d'introduire le swapping qui est donc complémentaire au
processus de mémoire virtuelle.

Tu noteras que l'on à:
De la mémoire virtuelle (qui n'existe pas physiquement)
et
De la mémoire physique qui elle est bien réelle et limitée: RAM et
fichiers de swap sur le disque dur

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.

Ben si.

Maintenant savoir pourquoi tant de mémoire virtuelle, je pense que ce
n'est pas explicable "comme çà" il faudrait être beaucoup plus intime
avec les algos et le code du sytème mais ce n'est pas physiquement à
notre portée ni de notre niveau (enfin pas du miens).

--
Gilbert

Vous avez filtré cet utilisateur ! Consultez son message

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.
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 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.

Maintenant, c'est sur que l'on va à la longue remplir la RAM. Le 3ème
paragraphe donne la solution employée:

"if there are no free pages available in physical memory, the handler
must first release an existing page to make room for the new page. How
the system release pages depends on the platform. In OS X, the virtual
memory system often writes pages to the backing store. The backing store
is a disk-based repository containing a copy of the memory pages used by
a given process. Moving data from physical memory to the backing store
is called paging out (or "swapping out"); moving data from the backing
store back in to physical memory is called paging in (or "swapping in").
In iOS, there is no backing store and so pages are are never paged out
to disk, but read-only pages are still be paged in from disk as needed."

On fait de la place en transférant un(des) bloc(s) de 4k sur le disque
dur et on vient d'introduire le swapping qui est donc complémentaire au
processus de mémoire virtuelle.

Tu noteras que l'on à:
De la mémoire virtuelle (qui n'existe pas physiquement)
et
De la mémoire physique qui elle est bien réelle et limitée: RAM et
fichiers de swap sur le disque dur

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.

Ben si.

Maintenant savoir pourquoi tant de mémoire virtuelle, je pense que ce
n'est pas explicable "comme çà" il faudrait être beaucoup plus intime
avec les algos et le code du sytème mais ce n'est pas physiquement à
notre portée ni de notre niveau (enfin pas du miens).

--
Gilbert

Patrick Stadelmann

29/01/2014 à 10:00

In article <1lg89jh.1pepk7310a28cgN%,
(Gilbert OLIVIER) wrote:

Maintenant savoir pourquoi tant de mémoire virtuelle, je pense que ce
n'est pas explicable "comme çà" il faudrait être beaucoup plus intime
avec les algos et le code du sytème mais ce n'est pas physiquement à
notre portée ni de notre niveau (enfin pas du miens).

C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
chaque process (dans les 2 Go).

Patrick
--
Patrick Stadelmann

Matt

29/01/2014 à 12:18

On Mer 29 janvier 2014 (07:19),
pehache wrote:

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 à des
allocations réellement présentes dans le code.

La totalité de ces addressages dépend des allocations requises par les
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 virtuelle,
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" à comprendre.

Que tu mélanges l'enchaînement des évènements c'est un fait mais dans
les explications il n'en est rien car le processus de swap est la suite
logique lorsqu'une allocation doit être écrite dans la mémoire physique
alors qu'il n'y a plus de place.

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.

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 dans
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.

--
“Software developers like to solve problems. If there are no problems handily
available, they will create their own problems.” – Anonymous

On Mer 29 janvier 2014 (07:19),
pehache <pehache.7@gmail.com> wrote:

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 à des
allocations réellement présentes dans le code.

La totalité de ces addressages dépend des allocations requises par les
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 virtuelle,
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" à comprendre.

Que tu mélanges l'enchaînement des évènements c'est un fait mais dans
les explications il n'en est rien car le processus de swap est la suite
logique lorsqu'une allocation doit être écrite dans la mémoire physique
alors qu'il n'y a plus de place.

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.

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 dans
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.

--
“Software developers like to solve problems. If there are no problems handily
available, they will create their own problems.” – Anonymous

Vous avez filtré cet utilisateur ! Consultez son message

On Mer 29 janvier 2014 (07:19),
pehache wrote:

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 à des
allocations réellement présentes dans le code.

La totalité de ces addressages dépend des allocations requises par les
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 virtuelle,
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" à comprendre.

Que tu mélanges l'enchaînement des évènements c'est un fait mais dans
les explications il n'en est rien car le processus de swap est la suite
logique lorsqu'une allocation doit être écrite dans la mémoire physique
alors qu'il n'y a plus de place.

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.

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 dans
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.

--
“Software developers like to solve problems. If there are no problems handily
available, they will create their own problems.” – Anonymous

gilbert.olivier

29/01/2014 à 12:33

Patrick Stadelmann wrote:

In article <1lg89jh.1pepk7310a28cgN%,
(Gilbert OLIVIER) wrote:

> Maintenant savoir pourquoi tant de mémoire virtuelle, je pense que ce
> n'est pas explicable "comme çà" il faudrait être beaucoup plus intime
> avec les algos et le code du sytème mais ce n'est pas physiquement à
> notre portée ni de notre niveau (enfin pas du miens).

C'est juste qu'OS X réserve un immense espace d'adressage virtuel pour
chaque process (dans les 2 Go).

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.

--
Gilbert

Taille Mémoire Virtuel : 243,62 Go!

10 réponses

Veuillez sélectionner un problème