• Author / Uploaded
• Nataniel Maggiora

Citation preview

•

Gestión de memoria en Windows

El gestor de memoria en Windows está hecho para trabajar con paginas que van de los 4kB hasta los 64kB. Cuando se crea un proceso el tamaño máximo es de 2GB, este espacio está dividido en páginas de tamaño fijo y poseen uno de los siguientes estados: • • •

Disponible Reservada Asignada

Cuando hay espacio disponible en la memoria, el gestor de memoria virtual permite que los conjuntos residentes de los procesos activos crezcan. Entonces se trae una nueva página a la memoria sin expulsar ninguna. Cuando la memoria empieza a escasear, el gestor de memoria virtual mueve las páginas que se han utilizado hace más tiempo de cada uno de los procesos hacia swap, liberando así memoria principal. Existen algunas similitudes en cuanto a la gestión de memoria en Windows y Linux pero cuando es necesario liberar memoria Windows lo hace una vez por segundo a diferencia en Linux que lo hace solo cuando es necesario, esto hace de Linux mas eficiente.

Windows El gestor de memoria esta diseñado para trabajar con páginas que van desde los 4 Kbytes hasta 64Kbytes. Las plataformas Intel, PowerPC, y MIPS tienen 4096 bytes por página y las plataformas DEC Alpha tienen 8192 bytes por página. Mapa de direcciones virtuales en Windows Los procesos de usuario en Windows puede ver un espacio de direcciones independientemente de 32 bits, permitiendo 4Gbytes de memoria por proceso. Por defecto una parte de esta memoria se reserva para el SO de manera que cada usuario dispone de 2Gbytes de espacio de direcciones posibles y todos los procesos lo comparten. Se puede modificar esto restringiendo al SO a solo 1Gbyte y 3Gbytes para el usuario, esto viene explicado en la documentación de Windows. Espacio de direcciones en Windows: •

0x00000000 a 0x0000FFFF reservada para ayudar a los programadores a capturar

asignaciones de punteros Nulos. • 0x00010000 a 0x7FFEFFFF espacio de direcciones disponible para el usuario. Este espacio de encuentra dividido en páginas que se pueden cargar a la memoria principal. • 0x7FFF0000 a 0x7FFFFFFF una página de guarda, no accesible para el usuario. Lo que hace es verificar referencias a punteros fuera del rango. • 0x80000000 a 0xFFFFFFFF espacio de direcciones del sistema. Esta área es de 2Gbytes se utiliza por parte del ejecutivo de Windows, el micronúcleo y los manejadores de dispositivos. Paginación Cuando se crea un proceso, puede, en principio utilizar todo el espacio de usuario de 2Gbytes(menos 128 Kbytes). Este espacio se encuentra dividido en páginas de tamaño fijo, cualquiera de las cuales se

puede cargar en la memoria principal. Estados de las páginas: • •

Disponible: Páginas que no están actualmente usadas por este proceso. Reservada: Conjunto de páginas contiguas que el gestor de memoria virtual separa para un

proceso pero que no se cuentan para la cuota • Asignada: Las páginas para las cuales el gestor de la memoria virtual ha reservado espacio en el fichero de paginación. La distinción entre memoria reservada y asignada es muy útil debido a que minimiza la cantidad de espacio de disco que debe guardarse para un proceso en particular, manteniendo espacio libre en disco para otros procesos; y permite que un hilo o un proceso declare una petición de una cantidad de memoria que puede proporcionarse rápidamente si se necesita. En Windows cuando se activa un proceso por primera vez se le asigna un cierto numero de marcos de página de la memoria principal como conjunto de trabajo. Cuando un proceso hace referencia ha un proceso que no esta en memoria principal, una de las páginas de dicho proceso se expulsa, y se trae la nueva página. Cuando hay espacio disponible en la memoria, el gestor de memoria virtual permite que los conjuntos residentes de los procesos activos crezcan. Entonces se trae una nueva página a la memoria sin expulsar ninguna. Cuando la memoria empieza a escasear, el gestor de memoria virtual mueve las páginas que se han utilizado hace más tiempo de cada uno de los procesos hacia swap, liberando así memoria principal.

Bibliografia: William Stallings (2005). Sistemas Operativos. España: Pearson. 384-388

For any type of app (Metro style or desktop), Windows tries to regulate physical memory allocations on behalf of that app, regardless of the memory requests it has made. Windows has always behaved this way to keep memory available in anticipation of future app memory needs. Windows is careful to only allocate physical memory to an app when the app tries to touch it, even if the app had “allocated” it earlier. Windows will also page out or repurpose parts of memory from an app if the pages of memory haven’t been touched in a long time. It is important to understand the goal is not to deny memory to a requesting process, but to delay allocating physical memory as long as possible (until the user actually touches the app) because as with many resources, there is a tendency for software to over-budget. The OS is the place where all these requests come together and it has the information to see that meeting all the fully budgeted requests would ultimately starve every process. Not only would work not complete, but the system will essentially lock up. This happens even if the memory is virtual—instead of running out of RAM, your PC would simply swap pages in and out of disk. The physical memory given to a process at any point in time is referred to as the “working set” of the process. A private working set represents physical memory that is unique to a process. Processes also touch other pages of physical memory that are “shared,” which several processes can reference. When you look at the Processes view in Task Manager, the memory for a specific process is actually its current private working set. NOTE: For simplicity, when I refer to “working set” in this blog, I mean “private working set.” When the system starts to run low on available memory, the OS will look in all processes for pages

of physical memory that it can repurpose to satisfy other needs in the system, even by paging out memory when necessary. For desktop apps, Windows will try to keep the most important (frequently accessed) pages of memory in the app’s working set; this is because desktop apps expect to be able to run code at any time, even when they’re in the background. It’s a fine balance though: if too many pages of memory were to be removed from a desktop app, it could affect the app’s responsiveness due to additional disk I/O (as the app tries to touch memory that has been paged to disk under the covers).

Reclaiming memory from suspended Metro style apps In Windows 8 Consumer Preview, we can efficiently write the whole (private) working set of a suspended Metro style app to disk, in order to gain additional memory when the system detects pressure. This process is analogous to hibernating a specific app, and then resuming it when the user switches back to the app. We’re taking advantage of the suspend/resume mechanism of Metro style apps to empty or re-populate an app’s working set. The sequence of events is described below: 1. The Process Lifetime Manager (PLM) detects memory pressure in the system and asks the Memory Manager (MM) to empty the working set of a specific process that houses a suspended Metro style app.

1.

MM moves the pages of memory from the working set of the app to the

operating system’s modified page list (which is a list of memory whose contents are to be written out to disk before being reused).

1. The working set pages on the modified page list are written out asynchronously, as dictated by the usual MM policies (written out opportunistically in the background, writes triggered when under memory pressure).

1.

Even after the suspended apps working set is written to disk, the memory

pages removed from a process are left intact on the operating system’s standby list. This is a cache of useful pages of memory that can be repurposed for other apps, if necessary. If these pages are immediately needed again by their original process, they are quickly moved back.

If a user switches back to the app while its working set pages are still in physical memory (on the modified page list or the standby list), it’s straightforward: the pages will be added back into the app’s process immediately. If they are no longer available, Windows will read in the app’s working set from disk in an optimized manner.

“Reclaiming memory” in action To get a feel for how this works, let’s walk through an example with real running code. The initial state is represented by the screenshot above. I had several Metro style apps running on a PC with 2GB of RAM. The Metro style apps were in the background, and therefore Windows suspended them. I then started opening more apps to drive up memory use on the system and trigger the new functionality. In the next screenshot, below, you’ll notice that I opened some apps in order to introduce additional memory pressure and induce the behavior described above. As you can see, Windows emptied the working sets of the suspended Metro style apps (highlighted).

Working sets of Metro style apps emptied Let’s compare the “before” and “after” working sets of the original Metro style apps (some of the “after” stats cannot be seen because Task Manager ran out of room to show all 27 launched apps):

Metro style app

Working set before (MB) Working set after (MB)

Flixster

23.5

0.5

Flow

15.2

0.6

Kindle

23.1

0.5

LiveComm

3.8

0.3

Lyrics

65.3

0.9

Maps

28.1

0.8

Remote Desktop

21.0

0.5

SkyDrive

23.1

0.5

Store

26.9

0.6

Weather

42.0

0.8

Windows Reader

9.2

0.4

So in this example, we liberated over 250 MB of physical RAM for other apps to use without shutting down the suspended apps.

Responsiveness when reading the working set back in A test for this new facility is how responsive a suspended app is after its working set contents are emptied and you decide to switch back to the app. While I was running this test, I used the “Lyrics” app as my indicator of responsiveness. The Lyrics app can display the lyrics of a song as well as play back a music video. When the Lyrics app goes to the background, it gets suspended, which stops the playback. After driving memory use to the point where working sets were emptied, I opened additional apps and used the system for a while to ensure that a swap back to the app was going to read the working set from disk. I then triggered the switch back to the Lyrics app (below).

Lyrics app’s working set is repopulated The key indicator I was looking for was how long it would take from the time I triggered the switch back to the app to the point where I could hear sound again. On a low-end machine, with a high memory load, it’s hard to perceive a difference in responsiveness when switching back to the app whose working set was being read from disk compared to when its working set was still in memory. Your mileage will vary though: the larger the working set, the longer it will take to read-in from disk.

We’re also continuing to reduce the amount we have to write to disk for Metro style apps and further optimizing this feature. This functionality is something that everyone with the Consumer Preview release can try for themselves. Just open up a number of Metro style apps and desktop apps to generate some memory pressure, and then switch back to a suspended Metro style app that has had its working set emptied. NOTE: Windows will still close Metro style apps if memory gets into the critical range. However, this feature will enable a system to run more applications before getting to that point.