memory-management - qué - memoria virtual pdf

¿Cuáles son las diferencias entre la memoria virtual y la memoria física? (5)

Estoy copiando descaradamente los extractos de la página del hombre de la parte superior

VIRT - Imagen virtual (kb) La cantidad total de memoria virtual utilizada por la tarea. Incluye todo el código, los datos y las bibliotecas compartidas, además de las páginas que se han intercambiado y las páginas que se han correlacionado pero no se han utilizado.
SWAP - Tamaño intercambiado (kb) Memoria que no es residente pero está presente en una tarea. Esta es la memoria que se ha intercambiado, pero podría incluir memoria adicional no residente. Esta columna se calcula al restar la memoria física de la memoria virtual

A menudo me confunden con el concepto de virtualización en los sistemas operativos. Considerando la RAM como la memoria física, ¿por qué necesitamos la memoria virtual para ejecutar un proceso?

¿Dónde se encuentra esta memoria virtual cuando el proceso (programa) del disco duro externo se lleva a la memoria principal (memoria física) para la ejecución?

¿Quién se ocupa de la memoria virtual y cuál es el tamaño de la memoria virtual?

Supongamos que si el tamaño de la RAM es de 4 GB (es decir, 2 ^ 32-1 espacios de direcciones) ¿cuál es el tamaño de la memoria virtual?

La memoria virtual es, entre otras cosas, una abstracción para darle al programador la ilusión de tener memoria infinita disponible en su sistema.

Las asignaciones de memoria virtual están hechas para corresponder a direcciones físicas reales. El sistema operativo crea y trata con estas asignaciones, utilizando la tabla de páginas, entre otras estructuras de datos para mantener las asignaciones. Las asignaciones de memoria virtual siempre se encuentran en la tabla de páginas o en una estructura de datos similar (en el caso de otras implementaciones de memoria virtual, quizás no deberíamos llamarla "tabla de páginas"). La tabla de páginas también se encuentra en la memoria física, a menudo en espacios reservados al núcleo que los programas de usuario no pueden escribir.

La memoria virtual suele ser más grande que la memoria física; no habría muchas razones para las asignaciones de memoria virtual si la memoria virtual y la memoria física tuvieran el mismo tamaño.

Solo la parte necesaria de un programa reside en la memoria, por lo general, este es un tema llamado "paginación". La memoria virtual y la paginación están estrechamente relacionadas, pero no con el mismo tema. Hay otras implementaciones de memoria virtual, como la segmentación.

Podría estar asumiendo que estoy equivocado aquí, pero apostaría a que las cosas que te resulta difícil entender tienen que ver con implementaciones específicas de memoria virtual, muy probablemente con paginación. No hay una sola forma de hacer paginación: hay muchas implementaciones y la que el libro de texto describe probablemente no sea la misma que aparece en sistemas operativos reales como Linux / Windows. Probablemente existan diferencias sutiles.

Podría contar miles de párrafos sobre la búsqueda ... pero creo que es mejor dejar una pregunta diferente dirigida específicamente a ese tema.

Los softwares se ejecutan en el sistema operativo en una premisa muy simple: requieren memoria. El sistema operativo del dispositivo lo proporciona en forma de RAM. La cantidad de memoria requerida puede variar: algunos softwares necesitan mucha memoria, otros requieren memoria miserable. La mayoría (si no todos) los usuarios ejecutan múltiples aplicaciones en el sistema operativo simultáneamente, y dado que la memoria es costosa (y el tamaño del dispositivo es finito), la cantidad de memoria disponible siempre es limitada. Dado que todos los softwares requieren una cierta cantidad de RAM, y todos ellos pueden ejecutarse al mismo tiempo, el sistema operativo tiene que encargarse de dos cosas:

Que el software siempre se ejecuta hasta que el usuario lo interrumpe, es decir, no se debe abortar automáticamente porque el sistema operativo se ha quedado sin memoria.
La actividad anterior, a la vez que mantiene un rendimiento respetable para los softwares en ejecución.

Ahora la pregunta principal se reduce a cómo se maneja la memoria. ¿Qué gobierna exactamente en qué lugar de la memoria se encuentran los datos que pertenecen a un software determinado?

Posible solución 1 : Permitir que los softwares individuales especifiquen explícitamente la dirección de memoria que usarán en el dispositivo. Supongamos que Photoshop declara que siempre usará direcciones de memoria que van de 0 a 1023 (imagina la memoria como una matriz lineal de bytes, de modo que el primer byte está en la ubicación 0 , 1024 thte está en la ubicación 1023 ), es decir, ocupa 1 GB memoria. Del mismo modo, VLC declara que ocupará un rango de memoria de 1244 a 1876 , etc.

Ventajas:

Cada aplicación tiene asignada previamente una ranura de memoria, por lo que cuando se instala y ejecuta, solo almacena sus datos en esa área de memoria, y todo funciona bien.

Desventajas:

Esto no escala. Teóricamente, una aplicación puede requerir una gran cantidad de memoria cuando está haciendo algo realmente pesado. Por lo tanto, para garantizar que nunca se quede sin memoria, el área de memoria asignada siempre debe ser mayor o igual a esa cantidad de memoria. ¿Qué pasa si un software, cuyo uso máximo de la memoria teórica es de 2 GB (por lo tanto, requiere 2 GB asignación de memoria de la RAM), se instala en una máquina con solo 1 GB memoria? ¿Debería el software abortar al inicio, diciendo que la memoria RAM disponible es de menos de 2 GB ? ¿O debería continuar, y en el momento en que la memoria requiera más de 2 GB , simplemente aborte y rescate con el mensaje de que no hay suficiente memoria disponible?
No es posible evitar la acumulación de memoria. Hay millones de softwares por ahí, incluso si a cada uno de ellos se le asignó solo 1 kB memoria, la memoria total requerida excederá los 16 GB , que es más de lo que ofrecen la mayoría de los dispositivos. Entonces, ¿cómo se pueden asignar diferentes softwares a las ranuras de memoria que no invaden las áreas de los demás? En primer lugar, no existe un mercado de software centralizado que pueda regularlo cuando se lanza un nuevo software, debe asignarse esta cantidad de memoria desde esta área aún desocupada , y en segundo lugar, incluso si lo hubiera, no es posible hacerlo porque el no. de softwares es prácticamente infinito (por lo tanto, requiere memoria infinita para acomodarlos a todos), y la RAM total disponible en cualquier dispositivo no es suficiente para acomodar incluso una fracción de lo requerido, haciendo inevitable la invasión de los límites de memoria de un software sobre el de otro. Entonces, ¿qué sucede cuando Photoshop tiene asignadas las ubicaciones de memoria 1 a 1023 y VLC tiene asignadas de 1000 a 1676 ? ¿Qué pasa si Photoshop almacena algunos datos en la ubicación 1008 , luego VLC sobrescribe eso con sus propios datos, y luego Photoshop accede a ella pensando que es la misma información que se había almacenado allí anteriormente? Como se puede imaginar, cosas malas sucederán.

Entonces, claramente, como pueden ver, esta idea es bastante ingenua.

Posible solución 2 : probemos otro esquema, donde OS hará la mayoría de la gestión de la memoria. Los softwares, siempre que requieran memoria, solo solicitarán el SO, y el SO se acomodará en consecuencia. Say OS garantiza que cada vez que un nuevo proceso solicite memoria, asignará la memoria desde la dirección de bytes más baja posible (como se dijo antes, la RAM se puede imaginar como una matriz lineal de bytes, por lo que para 4 GB RAM, el rango de direcciones para un byte de 0 a 2^32-1 ) si el proceso está comenzando, de lo contrario, si se trata de un proceso en ejecución que solicita la memoria, se asignará desde la última ubicación de memoria donde aún reside ese proceso. Dado que el software emitirá direcciones sin considerar cuál será la dirección de memoria real donde se almacenan esos datos, el sistema operativo tendrá que mantener una asignación, por software, de la dirección emitida por el software a la dirección física real (Nota: Esa es una de las dos razones por las que llamamos a este concepto Virtual Memory . Los softwares no se preocupan por la dirección de memoria real donde se almacenan sus datos, simplemente escupirán direcciones sobre la marcha, y el sistema operativo encuentra el lugar adecuado para encajar y encontrarlo más tarde si es necesario).

Supongamos que el dispositivo acaba de encenderse, el sistema operativo acaba de abrirse, ahora mismo no hay otro proceso en ejecución (ignorando el sistema operativo, que también es un proceso), y decide lanzar VLC . Entonces, a VLC se le asigna una parte de la RAM desde las direcciones de bytes más bajas. Bueno. Ahora, mientras se está ejecutando el video, debe iniciar su navegador para ver alguna página web. Luego debe iniciar el Bloc de notas para garabatear algo de texto. Y luego Eclipse para hacer algo de codificación ... Muy pronto su memoria de 4 GB se 4 GB y la RAM se ve así:

Problema 1: Ahora no puede iniciar ningún otro proceso, ya que toda la RAM está agotada. Por lo tanto, los programas deben escribirse teniendo en cuenta la memoria máxima disponible (¡prácticamente habrá menos disponibles, ya que otros softwares también se ejecutarán paralelamente!). En otras palabras, no puedes ejecutar una aplicación que consuma mucha memoria en tu ramshackle de 1 GB .

De acuerdo, ahora que decides que ya no necesitas mantener abiertos Eclipse y Chrome , los cierras para liberar algo de memoria. El espacio ocupado en la RAM por esos procesos es recuperado por el sistema operativo, y se ve así ahora:

Supongamos que estos dos liberan 700 MB espacio - ( 400 + 300 ) MB. Ahora debe iniciar Opera , que ocupará 450 MB espacio. Bueno, tienes más de 450 MB espacio disponible en total, pero ... no es contiguo, está dividido en trozos individuales, ninguno de los cuales es lo suficientemente grande para 450 MB . Entonces, si tiene una idea brillante, llevemos todos los procesos a la posición más alta posible, lo que dejará los 700 MB espacio vacío en un pedazo en la parte inferior. Esto se llama compaction . Genial, excepto que ... todos los procesos que están ahí se están ejecutando. Moverlos significa mover la dirección de todos sus contenidos (recuerde, el sistema operativo mantiene una asignación de la memoria escupida por el software a la dirección de memoria real.) El software Imagine había escupido una dirección de 45 con datos 123 , y el sistema operativo lo había almacenado en la ubicación 2012 y creó una entrada en el mapa, mapeando 45 a 2012 Si el software ahora se mueve en la memoria, lo que solía ser en la ubicación 2012 ya no estará en 2012 , sino en una nueva ubicación, y el sistema operativo tiene que actualizarse el mapa corresponde al mapa 45 a la nueva dirección, de modo que el software puede obtener los datos esperados ( 123 ) cuando consulta la ubicación de la memoria 45 En lo que respecta al software, todo lo que sabe es que la dirección 45 contiene los datos 123 !)! Imagine un proceso que hace referencia a una variable local i . Para cuando se acceda nuevamente, su dirección ha cambiado y ya no podrá encontrarla. Lo mismo ocurrirá con todas las funciones, objetos, variables, básicamente todo tiene una dirección, y mover un proceso significará cambiar la dirección de todos ellos. Lo que nos lleva a:

Problema 2: No puedes mover un proceso. Los valores de todas las variables, funciones y objetos dentro de ese proceso tienen valores codificados por el compilador durante la compilación, el proceso depende de que estén en el mismo lugar durante su vida útil, y cambiarlos es costoso. Como resultado, los procesos dejan grandes " holes " cuando salen. Esto se llama External Fragmentation .

Multa. Supongamos que de alguna manera, de una manera milagrosa, logras mover los procesos hacia arriba. Ahora hay 700 MB de espacio libre en la parte inferior:

Opera se adapta suavemente en la parte inferior. Ahora su RAM se ve así:

Bueno. Todo se ve bien. Sin embargo, no queda mucho espacio y ahora debes volver a ejecutar Chrome , ¡un conocido sabueso de memoria! Necesita mucha memoria para comenzar, y apenas le queda nada ... Excepto ... ahora observa que algunos de los procesos, que inicialmente ocupaban un gran espacio, ahora no necesitan mucho espacio. Puede ser que hayas detenido tu video en VLC , por lo tanto, todavía ocupa un poco de espacio, pero no tanto como se requiere al ejecutar un video de alta resolución. Del mismo modo para Notepad y fotos . Su RAM ahora se ve así:

Holes , una vez más! ¡Volver al punto de partida! Excepto, previamente, los agujeros ocurrieron debido a que los procesos terminaron, ¡ahora se debe a procesos que requieren menos espacio que antes! Y nuevamente tiene el mismo problema, los holes combinados producen más espacio de lo requerido, pero están dispersos, no se usan mucho en forma aislada. Entonces, tiene que mover esos procesos nuevamente, una operación costosa, y muy frecuente, ya que los procesos con frecuencia se reducirán en tamaño a lo largo de su vida útil.

Problema 3: los procesos, a lo largo de su vida útil, pueden reducir su tamaño, dejando atrás el espacio no utilizado, que de ser necesario, requerirá la costosa operación de mover muchos procesos. Esto se llama Internal Fragmentation .

Bien, ahora su sistema operativo hace lo necesario, mueve los procesos e inicia Chrome y después de un tiempo, su RAM se ve así:

Guay. Ahora supongamos que vuelves a ver Avatar en VLC . ¡Su requisito de memoria se disparará! Pero ... no queda espacio para que crezca, ya que el Bloc de notas se acurruca en su parte inferior. Entonces, de nuevo, todos los procesos deben moverse hacia abajo hasta que VLC haya encontrado suficiente espacio.

Problema 4: si los procesos necesitan crecer, será una operación muy costosa

Multa. Ahora supongamos que Photos se usa para cargar algunas fotos de un disco duro externo. Acceder al disco duro lo lleva del dominio de cachés y RAM al del disco, que es más lento por órdenes de magnitud. Dolorosa, irrevocablemente, trascendentalmente más lento. Es una operación de E / S, lo que significa que no está unida a la CPU (es más bien lo contrario), lo que significa que no necesita ocupar la RAM en este momento. Sin embargo, todavía ocupa RAM con terquedad. Si desea ejecutar Firefox mientras tanto, no puede, porque no hay mucha memoria disponible, mientras que si Photos se sacó de la memoria durante la duración de su actividad de E / S encuadernada, habría liberado mucha memoria, seguido de una compactación (costosa), seguida de la instalación de Firefox .

Problema 5: los trabajos enlazados de E / S continúan ocupando la RAM, lo que lleva a una infrautilización de la RAM, que podría haber sido utilizada por los trabajos vinculados a la CPU mientras tanto.

Entonces, como podemos ver, tenemos tantos problemas incluso con el enfoque de la memoria virtual.

Hay dos enfoques para abordar estos problemas: paging y segmentation . Déjanos hablar de la paging . En este enfoque, el espacio de direcciones virtuales de un proceso se asigna a la memoria física en fragmentos, llamados pages . Un tamaño de page típico es de 4 kB . El mapeo es mantenido por algo llamado page table , dada una dirección virtual, todo lo que tenemos que hacer ahora es encontrar a qué page pertenece la dirección, luego desde la page table , encontrar la ubicación correspondiente para esa page en la memoria física real ( conocido como frame ), y dado que el desplazamiento de la dirección virtual dentro de la page es el mismo para la page que para el frame , descubra la dirección real al agregar esa compensación a la dirección devuelta por la page table . Por ejemplo:

A la izquierda está el espacio de direcciones virtuales de un proceso. Digamos que el espacio de direcciones virtuales requiere 40 unidades de memoria. Si el espacio de direcciones físicas (a la derecha) también tuviese 40 unidades de memoria, habría sido posible mapear todas las ubicaciones desde la izquierda a una ubicación a la derecha, y estaríamos tan contentos. Pero como la mala suerte lo tendría, la memoria física no solo tiene menos (24 aquí) unidades de memoria disponibles, sino que también debe compartirse entre múltiples procesos. Bien, veamos cómo nos arreglamos con eso.

Cuando comienza el proceso, digamos que se realiza una solicitud de acceso a memoria para la ubicación 35 . Aquí el tamaño de página es 8 (cada page contiene 8 ubicaciones, el espacio completo de direcciones virtuales de 40 ubicaciones contiene 5 páginas). Entonces esta ubicación pertenece a la página no. 4 ( 35/8 ). Dentro de esta page , esta ubicación tiene un desplazamiento de 5 ( 35%8 ). Entonces esta ubicación puede ser especificada por la tupla (pageIndex, offset) = (4,3) . Este es solo el comienzo, por lo que ninguna parte del proceso se almacena en la memoria física actual. Por lo tanto, la page table , que mantiene una asignación de las páginas de la izquierda a las páginas reales a la derecha (donde se llaman frames ) está actualmente vacía. Así que OS renuncia a la CPU, permite que un controlador de dispositivo acceda al disco y busque el no. 4 para este proceso (básicamente un fragmento de memoria del programa en el disco cuyas direcciones van desde 32 a 39 ). Cuando llega, OS asigna la página en algún lugar de la RAM, por ejemplo, el primer cuadro, y la page table para este proceso toma nota de que la página 4 asigna al cuadro 0 en la RAM. Ahora los datos finalmente están ahí en la memoria física. OS vuelve a consultar la tabla de páginas para la tupla (4,3) , y esta vez, la tabla de páginas dice que la página 4 ya está asignada al cuadro 0 en la RAM. Así que OS simplemente va al marco número 0 en la RAM, accede a los datos en el desplazamiento 3 en ese cuadro (tómese un momento para comprender esto. Toda la page , que fue extraída del disco, se mueve al frame . la ubicación de la memoria individual en una página era, será lo mismo en el marco, ya que dentro de la page / frame , la unidad de memoria aún reside en el mismo lugar relativamente!), ¡y devuelve los datos! Debido a que los datos no se encontraron en la memoria en la primera consulta en sí, sino que tuvieron que ser extraídos del disco para ser cargados en la memoria, constituye una falla .

Multa. Ahora supongamos que se hace un acceso de memoria para la ubicación 28 . Se reduce a (3,4) . Page table ahora solo tiene una entrada, asignando la página 4 al cuadro 0 . Por lo tanto, esto es otra vez una falla , el proceso renuncia a la CPU, el controlador de dispositivo recupera la página del disco, el proceso recupera nuevamente el control de la CPU y se actualiza su page table . Digamos ahora que la página 3 está mapeada al cuadro 1 en la RAM. Entonces (3,4) convierte en (1,4) y se devuelven los datos en esa ubicación en la RAM. Bueno. De esta forma, supongamos que el siguiente acceso a la memoria es para la ubicación 8 , que se traduce en (1,0) . La página 1 todavía no está en la memoria, se repite el mismo procedimiento y la page se asigna al cuadro 2 en la RAM. Ahora la asignación del proceso de RAM se parece a la imagen anterior. En este momento, la RAM, que tenía solo 24 unidades de memoria disponibles, se llena. Supongamos que la siguiente solicitud de acceso a memoria para este proceso es desde la dirección 30 . Se asigna a (3,6) , y la page table dice que la página 3 está en RAM, y se mapea en el cuadro 1 . ¡Hurra! Entonces los datos se obtienen de la ubicación de la RAM (1,6) y se devuelven. Esto constituye un golpe , ya que los datos requeridos se pueden obtener directamente de la memoria RAM, por lo que es muy rápido. De manera similar, las siguientes pocas solicitudes de acceso, por ejemplo para las ubicaciones 11 , 32 , 26 , 27 , todas son aciertos , es decir, los datos solicitados por el proceso se encuentran directamente en la RAM sin necesidad de buscar en otra parte.

Ahora suponga que viene una solicitud de acceso a la memoria para la ubicación 3 . Se traduce a (0,3) , y la page table para este proceso, que actualmente tiene 3 entradas, para las páginas 1 , 3 y 4 dice que esta página no está en la memoria. Al igual que en los casos anteriores, se extrae del disco; sin embargo, a diferencia de los casos anteriores, ¡la RAM está llena! Entonces, ¿qué hacer ahora? ¡Aquí yace la belleza de la memoria virtual, un marco de la memoria RAM se desahució! (Varios factores determinan qué marco debe desalojarse. Puede estar basado en LRU , donde el marco al que se accedió menos recientemente para un proceso debe ser desalojado. Puede ser el first-cum-first-evicted ser first-cum-first-evicted , donde el marco asignado hace mucho tiempo, se desaloja, etc.) Por lo tanto, se desaloja un marco. Diga el cuadro 1 (simplemente escogiéndolo al azar). Sin embargo, ese frame está mapeado en alguna page ! (Actualmente, está mapeado por la tabla de páginas de nuestro único y único proceso de la página 4 ). Entonces, ese proceso debe ser contado en esta noticia trágica, ese frame , que desafortunadamente te pertenece, será desalojado de la memoria RAM para dejar espacio para otras pages . El proceso debe garantizar que actualiza su page table con esta información, es decir, eliminar la entrada para ese dúo de marcos de página, de modo que la próxima vez que se realice una solicitud para esa page , indique el proceso correcto de que esta page está ya no está en la memoria, y tiene que ser extraído del disco. Bueno. Entonces, el marco 1 se desaloja, la página 0 se coloca y se coloca allí en la RAM, y se elimina la entrada para la página 4 , y se reemplaza por la asignación de la página 0 al mismo cuadro 1 . Así que ahora nuestra asignación se ve así (observe el cambio de color en el segundo frame en el lado derecho):

Viste lo que acaba de pasar? El proceso tenía que crecer, necesitaba más espacio que la RAM disponible, pero a diferencia de nuestro escenario anterior en el que cada proceso en la RAM tenía que moverse para acomodar un proceso de crecimiento, ¡aquí sucedió con solo un reemplazo de page ! Esto fue posible por el hecho de que la memoria para un proceso ya no necesita ser contigua, puede residir en diferentes lugares en fragmentos, el sistema operativo mantiene la información en cuanto a dónde se encuentran, y cuando es necesario, se los consulta apropiadamente. Nota: es posible que esté pensando, eh, ¿qué pasa si la mayoría de las veces es una miss , y los datos tienen que cargarse constantemente desde el disco a la memoria? Sí, teóricamente, es posible, pero la mayoría de los compiladores están diseñados de tal manera que sigue la locality of reference , es decir, si se utilizan datos de alguna ubicación de memoria, los siguientes datos necesarios se ubicarán en algún lugar muy cercano, quizás desde la misma page . la page que acaba de cargarse en la memoria. Como resultado, la próxima falla se producirá después de bastante tiempo, la mayoría de los requisitos de memoria venidera se cumplirán con la página que acaba de entrar, o las páginas que ya se han utilizado recientemente en la memoria. El mismo principio exacto nos permite desalojar también la page usó menos recientemente, con la lógica de que lo que no se usó por un tiempo, probablemente no se use en un tiempo. Sin embargo, no siempre es así, y en casos excepcionales, sí, el rendimiento puede sufrir. Más sobre eso más tarde.

Solución al problema 4: los procesos ahora pueden crecer fácilmente, si se enfrenta un problema de espacio, todo lo que se requiere es hacer un simple reemplazo de page , sin mover ningún otro proceso.

Solución al problema 1: un proceso puede acceder a la memoria ilimitada. Cuando se necesita más memoria que la disponible, el disco se utiliza como copia de seguridad, los nuevos datos requeridos se cargan en la memoria del disco y el frame datos (o page ) utilizado menos recientemente se mueve al disco. Esto puede continuar infinitamente, y dado que el espacio en disco es barato y virtualmente ilimitado, da una ilusión de memoria ilimitada. Otra razón para el nombre Virtual Memory , ¡te da una ilusión de memoria que no está realmente disponible!

Guay. Anteriormente nos enfrentamos a un problema donde, aunque un proceso se reduce en tamaño, el espacio vacío es difícil de recuperar por otros procesos (porque requeriría una costosa compactación). Ahora es fácil, cuando un proceso se vuelve más pequeño, muchas de sus pages ya no se utilizan, por lo que cuando otros procesos necesitan más memoria, un simple desalojo basado en LRU expulsa automáticamente esas pages menos utilizadas de la RAM y las reemplaza con nuevas páginas de los otros procesos (y, por supuesto, la actualización de las page tables de page tables de todos esos procesos, así como el proceso original que ahora requiere menos espacio), ¡todo esto sin ninguna costosa operación de compactación!

Solución al problema 3: cada vez que los procesos se reducen, sus frames en RAM serán menos utilizados, por lo que un simple desalojo basado en LRU puede desalojar esas páginas y reemplazarlas por pages requeridas por procesos nuevos, evitando así Internal Fragmentation sin necesidad de compaction .

En cuanto al problema 2, tómese un momento para comprender esto, el escenario en sí mismo se elimina por completo. No hay necesidad de mover un proceso para acomodar un nuevo proceso, porque ahora el proceso completo nunca tiene que encajar a la vez, solo ciertas páginas de él deben ajustarse ad hoc, lo que sucede al expulsar los frames de la RAM. ¡Todo sucede en unidades de pages , por lo tanto, no hay ningún concepto de hole ahora, y por lo tanto, no hay duda de que algo se mueva! Es posible que haya que mover 10 pages debido a este nuevo requisito, hay miles de pages que no se han modificado. Mientras que, antes, ¡todos los procesos (cada uno de ellos) tenían que moverse!

Solución al problema 2: para dar cabida a un nuevo proceso, los datos de las partes de procesos que se utilizaron menos recientemente tienen que ser desalojados según sea necesario, y esto ocurre en unidades de tamaño fijo llamadas pages . Por lo tanto, no hay posibilidad de hole o External Fragmentation con este sistema.

Ahora, cuando el proceso necesita hacer alguna operación de E / S, ¡puede renunciar a la CPU fácilmente! El sistema operativo simplemente desaloja todas sus pages de la memoria RAM (quizás lo almacene en algún caché) mientras que los nuevos procesos ocupan la memoria RAM mientras tanto. Cuando finaliza la operación de E / S, OS simplemente restaura esas pages en la RAM (por supuesto, reemplazando las pages de otros procesos, pueden ser de las que reemplazaron el proceso original, o pueden ser de algunas que ellos mismos deben hacer) E / S ahora, y por lo tanto puede renunciar a la memoria!)

Solución al problema 5: cuando un proceso realiza operaciones de E / S, puede renunciar fácilmente al uso de RAM, que puede ser utilizado por otros procesos. Esto lleva a una utilización adecuada de la RAM.

Y, por supuesto, ahora ningún proceso está accediendo directamente a la RAM. Cada proceso está accediendo a una ubicación de memoria virtual, que está asignada a una dirección de RAM física y mantenida por la page-table de page-table de ese proceso. La asignación está respaldada por el sistema operativo, el sistema operativo le permite al proceso saber qué marco está vacío para que allí pueda instalarse una nueva página para un proceso. Como esta asignación de memoria es supervisada por el sistema operativo en sí, puede garantizar fácilmente que ningún proceso invada el contenido de otro proceso al asignar solo marcos vacíos desde la RAM, o al invadir el contenido de otro proceso en la RAM, comunicarse con el proceso para actualizarlo en page-table .

Solución al problema original: no hay posibilidad de que un proceso acceda a los contenidos de otro proceso, ya que la asignación completa es administrada por el sistema operativo en sí, y cada proceso se ejecuta en su propio espacio de direcciones virtuales con espacio aislado.

¡Así que la paging (entre otras técnicas), junto con la memoria virtual, es lo que impulsa los softwares de hoy en día en OS-es! Esto libera al desarrollador de software de la cantidad de memoria disponible en el dispositivo del usuario, dónde almacenar los datos, cómo evitar que otros procesos corrompan los datos de su software, etc. Sin embargo, por supuesto, no es a prueba total. Hay defectos:

Paging , en última instancia, le da al usuario la ilusión de una memoria infinita al usar el disco como respaldo secundario. Recuperar datos del almacenamiento secundario para que quepan en la memoria (llamado page swap , y el evento de no encontrar la página deseada en la RAM se llama page fault ) es costoso ya que es una operación IO. Esto ralentiza el proceso. Varios de estos intercambios de páginas ocurren en sucesión y el proceso se vuelve extremadamente lento. ¿Has visto alguna vez que tu software funcione correctamente y de repente, se vuelve tan lento que casi se bloquea o te deja sin opción de reiniciarlo? Es posible que haya demasiados cambios de página, lo que hace que sea lento (lo que se conoce como thrashing ).

Así que volviendo a OP,

¿Por qué necesitamos la memoria virtual para ejecutar un proceso? - Como explica detalladamente la respuesta, proporcionar al software la ilusión de que el dispositivo / sistema operativo tenga memoria infinita, de modo que cualquier software, grande o pequeño, pueda ejecutarse sin preocuparse por la asignación de memoria u otros procesos que corrompan sus datos, incluso cuando corriendo en paralelo. Es un concepto, implementado en la práctica a través de varias técnicas, una de las cuales, como se describe aquí, es Paginación . También puede ser Segmentación .

¿Dónde se encuentra esta memoria virtual cuando el proceso (programa) del disco duro externo se lleva a la memoria principal (memoria física) para la ejecución? - La memoria virtual no se encuentra en ningún lugar per se, es una abstracción, siempre presente, cuando se inicia el software / proceso / programa, se crea una nueva tabla de páginas para ella, y contiene el mapeo de las direcciones escupidas por ese procesar a la dirección física real en la RAM. Dado que las direcciones escupidas por el proceso no son direcciones reales, en cierto sentido, son, en realidad, lo que puede decir, the virtual memory .

¿Quién se ocupa de la memoria virtual y cuál es el tamaño de la memoria virtual? - Es atendido por, en conjunto, el sistema operativo y el software. Imagina una función en tu código (que finalmente compila y convierte en el ejecutable que generó el proceso) que contiene una variable local, una int i . Cuando el código se ejecuta, obtengo una dirección de memoria dentro de la pila de la función. Esa función se almacena a sí misma como un objeto en otro lugar. Estas direcciones son generadas por el compilador (el compilador que compiló su código en el ejecutable): direcciones virtuales. Cuando se ejecuta, i que residir en alguna parte de la dirección física real para la duración de esa función al menos (a menos que sea una variable estática), por lo que OS mapea la dirección virtual generada por el compilador i en una dirección física real, de modo que siempre, dentro de esa función, algún código requiere el valor de i , ese proceso puede consultar el sistema operativo para esa dirección virtual, y el sistema operativo a su vez puede consultar la dirección física del valor almacenado y devolverlo.

Supongamos que si el tamaño de la RAM es de 4 GB (es decir, 2 ^ 32-1 espacios de direcciones) ¿cuál es el tamaño de la memoria virtual? - El tamaño de la RAM no está relacionado con el tamaño de la memoria virtual, depende del sistema operativo. Por ejemplo, en Windows de 32 bits, es de 16 TB , en Windows de 64 bits, es de 256 TB . Por supuesto, también está limitado por el tamaño del disco, ya que es allí donde se realiza la copia de seguridad de la memoria.

Vea aquí: https://en.wikibooks.org/wiki/Operating_System_Design/Physical_Memory

La memoria física se refiere a la RAM real del sistema, que generalmente toma la forma de tarjetas (DIMM) conectadas a la placa base. También llamado memoria primaria, es el único tipo de almacenamiento directamente accesible para la CPU y contiene las instrucciones de los programas para ejecutar. La memoria física es direccionable linealmente; las direcciones de memoria aumentan de forma lineal y cada byte es directamente direccionable.

La memoria virtual agrega una capa de abstracción sobre la memoria física y ofrece muchos beneficios, como la capacidad de mantener espacios de direcciones separados (tal vez por proceso) y la capacidad de usar la memoria física como un gran caché para el disco físico que hace que la memoria ilimitado (hasta 2 ^ (ancho del bus)) desde la perspectiva del programa / programador.

Vea aquí: Physical Vs Virtual Memory

La memoria virtual se almacena en el disco duro y se utiliza cuando se llena la memoria RAM. La memoria física está limitada al tamaño de los chips de RAM instalados en la computadora. La memoria virtual está limitada por el tamaño del disco duro, por lo que la memoria virtual tiene la capacidad de más almacenamiento.