Hola a todos, bienvenidos a una nueva videotutoria de la asignatura
Ampliación de Sistemas Operativos. En esta videotutoria vamos a empezar a
ver el tema 4 de la asignatura. El tema 4 de la asignatura lo podéis
encontrar en la página 143 del libro de texto y como veis en el título
del capítulo vamos a ver la administración de la memoria. Veis aquí que
el tema 4 consistiría en ver la administración de memoria en los sistemas
operativos basados en Unity. Entonces, en primer lugar, en la página 144 y
parte de la página 145 tenéis una introducción. De lo que se va a ver en
el tema y lo que va a ser el tema en sí. Yo os he hecho una especie de
resumen de esta introducción para que os situéis ahora al principio de
las partes que os vais a encontrar en el tema. ¿De acuerdo? Como
decíamos, el tema está dedicado a describir la administración de memoria
en los sistemas operativos basados en Unix y nos vamos a ir a la parte de
abajo. Y vamos a encontrar cuatro partes claramente diferenciadas en el
tema. ¿De acuerdo? La primera de ellas, o la primera parte, consistirá en
ver la gestión del espacio de direcciones virtuales de un proceso. ¿De
acuerdo? Luego, veremos una segunda parte en la que analizaremos la
traducción de direcciones virtuales a direcciones físicas. ¿De acuerdo?
Es decir, vamos a ver cómo se realiza esa traducción de direcciones. A
continuación, pasaríamos a ver una descripción de la gestión de la
memoria física y por último, veríamos una descripción de la gestión de
la memoria perteneciente al núcleo. ¿Vale? Esas serían las cuatro partes
en las que va a consistir el tema 4. Podéis leer vosotros mismos toda esa
introducción, que os da más detalles, pero el resumen sería básicamente
este que os he hecho yo. Vamos a empezar con la primera parte. La primera
parte la encontráis en el apartado 4.2 y que aparece en la página 145. Se
titula Gestión del espacio de direcciones virtuales de un proceso en los
sistemas operativos basados en UNIX. Y en primer lugar, vamos a ver cómo
es la organización de ese espacio de direcciones virtuales de un proceso.
¿De acuerdo? Bien. En el espacio de direcciones virtuales de un proceso,
se pueden distinguir diferentes regiones o segmentos. ¿Vale? Cada una de
esas regiones o cada uno de esos segmentos delineados. Y cada uno de esos
segmentos necesita un área contigua de memoria virtual. ¿Vale? Y vamos a
pasar ahora a ver cuáles son esos segmentos o esas regiones. En primer
lugar, tendríamos la región de código, ¿no? La región de código
también se denomina región de texto. Podéis encontrarlo en el examen o
en diferentes textos con esas dos denominaciones. En la teoría de
arquitecturas, comienza en la primera dirección virtual del espacio de
direcciones virtuales de ese proceso. Es decir, empieza en la primera
dirección virtual que tiene el proceso. Contiene las instrucciones
máquina del código del programa para cuya ejecución se ha creado el
proceso. Esto también es muy importante que lo sepáis, que sepáis que
contiene esa región de código. Y contendría las instrucciones máquina
de ese código del programa para cuya ejecución se ha creado el proceso.
Como dato curioso podéis apuntar que el contenido y el tamaño de la
región de código no varía durante la ejecución del proceso. Siempre es
constante, tanto el contenido como el tamaño de dicha región. Luego
tendríamos otro tipo de región que se denomina región de datos. La
región de datos se situaría a continuación de la región de código que
hemos visto anteriormente. Esta región de datos contiene las constantes y
las variables que han sido utilizadas en el código del programa. Además,
esta región se dividiría en dos partes. Por un lado estaría la región
de datos inicializados, que contiene los datos que tienen asignado un valor
inicial de forma explícita. Hay una serie de datos que nosotros le damos
un valor al comienzo y entonces esos datos o sus valores aparecen
reflejados en la región de datos inicializados. Y la otra parte sería la
región de datos no inicializados. Esta región contendría todos aquellos
datos que no han sido inicializados de forma explícita. Todos estos datos
que al inicio no hemos inicializado, por defecto se inicializarían a cero.
Esto tenerlo en cuenta, lo pongo aquí en rojo para que sepáis exactamente
qué valor se le da a todos estos datos que no se inicializan de manera
explícita. Luego tendríamos... El montículo. El montículo sería el
tamaño de la región de datos, os dice el libro, que puede ser aumentado
dinámicamente durante la ejecución del proceso. Para ello se podría
utilizar la función de librería malloc, que internamente utilizaría las
llamadas al sistema BRK o SBRK. Y a ese espacio extra, añadido a la
región de datos con respecto a su tamaño inicial, es lo que conocemos
como montículo o en inglés HIP. Entonces, que sepáis que os doy aquí
una pequeña introducción, creo que la definición de montículo sería el
espacio extra que ha sido añadido a la región de datos con respecto al
tamaño que tenía inicialmente. El sentido de crecimiento del montículo
depende del software, o sea, del hardware, perdón. Entonces, cada sistema
operativo basado en Unix lo establece dependiendo del hardware, depende de
qué sistema operativo estemos utilizando en cada momento. Para liberar un
espacio asignado en el montículo se utilizaría la llamada sistema free.
Entonces, también apuntarla por ahí para que sepáis cómo liberar un
espacio asignado. Otra región sería la región de pila. En esta región
se implementa la pila de usuario del proceso o las pilas de los hilos del
proceso. Inicialmente, esta región contiene todas las variables del
entorno del intérprete de comando, desde el que fue invocado el programa.
Además, contiene... La cadena de caracteres que esté asociada a la orden
con que fue invocado el programa, ¿de acuerdo? Que es lo que viene a ser
lo mismo que el nombre del programa y sus argumentos de entrada. Entonces,
el nombre del programa y los argumentos que introducimos como entrada
sería lo que viene contenido en la cadena de caracteres asociada al
programa. a la región de PIN. Otra región sería la región de
librerías. Estamos en la página 146. Esta región contendría las
diferentes librerías de funciones que han sido utilizadas por el programa.
El programa a lo largo de su ejecución utilizará diferentes librerías de
funciones y todas estas están contenidas en la región de librerías.
Deciros que estas librerías suelen ser compartidas por varios programas y
son implementadas mediante el mapeo en memoria de los archivos. Lo veremos
más adelante en este tema 4. En una librería se distinguen dos partes, el
código y los datos. También nos encontramos con otros tipos de regiones.
Otros tipos de regiones se pueden distinguir en el espacio de direcciones
virtuales de un proceso y serían las regiones de memoria compartida
utilizadas como recurso IPC y los archivos mapeados en memoria. También
hablaremos de todo esto de nuevo en la sección 4.2.2. Las librerías
serían un ejemplo de este último tipo de de región. Pueden marcarlo
aquí en rojo como muy importante por si os pidiesen el examen. Que
dijeseis un ejemplo de este último tipo de regiones, pues que indiquéis
que serían las librevigilantes. La distribución de las regiones y el
tamaño máximo del espacio de direcciones virtuales de un proceso serían
fijados por cada sistema operativo que esté basado en Unix en función del
hardware, como en el caso anterior. ¿Vale? Dependiendo del hardware, cada
sistema operativo hará la distribución de las regiones y el tamaño
máximo del espacio de direcciones virtuales en un determinado proceso. Y
ahora vamos a pasar a esa famosa sección 4.2.2 de la que hemos tenido
referencias en los apartados anteriores y en este apartado es donde vamos a
ver el mapeado de archivos en memoria. ¿De acuerdo? Este apartado 4.2.2 lo
podéis ver en la página 148. Deciros que ahí tenéis un ejemplo, en la
146 de lo visto anteriormente, que sería el ejemplo 4.1. ¿Vale? Este
ejemplo sería una muestra de la organización del espacio de direcciones
virtuales que realiza un determinado sistema operativo basado en Unix en
concreto. En este caso sería Solaris. ¿De acuerdo? ¿Vale? Pasando de
nuevo al apartado 4.2.2 de la página 148, dice lo siguiente sobre el
mapeado de archivos en memoria. Una operación de lectura o escritura a un
determinado bloque de datos de un archivo que esté ubicada en memoria
secundaria requerirá por parte de un proceso A la invocación de tres
llamadas al sistema como máximo. Estas llamadas al sistema son las
siguientes que os digo. Por un lado, la llamada al sistema OPEN, que
serviría para abrir el archivo, si es que no estaba abierto con
anterioridad. Por otro lado, la llamada al sistema LSIC, que sería la
encargada de posicionar el puntero de lectura y escritura que esté
asociado al archivo en la posición adecuada, si no es que estaba ya
posicionado. Y por último, la llamada al sistema READ o WRITE, que sería
para leer o escribir el bloque de datos. La llamada al sistema READ para
leer y la llamada al sistema WRITE para escribir. En el caso de una
operación de lectora, en primer lugar hay que realizar una operación de
entrada-salida a disco para leer el bloque en el disco y copiarlo a
continuación en un buffer de la caché de buffers del núcleo memoria
principal. A continuación, ese bloque sería copiado desde el buffer en el
espacio de direcciones virtuales del proceso A. Esta sería una forma
tradicional de acceder, de acceder a un archivo, pero genera un desperdicio
de memoria principal y resulta lenta. También tenerlo en cuenta. ¿Por
qué resulta un desperdicio y resulta lenta? Pues porque involucra la
realización de varias llamadas al sistema, como acabamos de ver. Habría
una forma más eficiente y rápida de acceder a un archivo y consistiría
en mapearlo en memoria principal sería digamos pues una mejora a esa forma
de acceso a un archivo un archivo mapeado en memoria es una región del
espacio de direcciones virtuales de un proceso en la que se establece una
correspondencia byte a byte con parte o con la totalidad de un archivo
entonces eso tenerlo en cuenta para que sepáis bien la definición de
archivo mapeado en memoria para establecer esta correspondencia que
acabamos de escribir el núcleo debe configurar las estructuras de datos
que mantiene para gestionar el espacio de dirección virtual de un proceso
lo veremos en la siguiente sección una vez que ha sido mapeado en memoria
el acceso determinado en el archivo puede ser realizado como a cualquier
otro contenido del espacio de direcciones virtuales indicando la dirección
virtual oportuna de esta manera evitaríamos tener que realizar llamadas al
sistema y por lo tanto introducir ese inconveniente que habíamos visto
antes que era el de la lentitud y el desperdicio de memoria principal de la
forma tradicional. Acordaos de este detalle porque es interesante e
importante. No son los inconvenientes del mapeado, ¿de acuerdo? Sino de la
forma tradicional de acceder a un archivo. Bien, aparte del ahorro de
memoria principal y de la rapidez que hemos conseguido gracias al mapeo,
otra ventaja sería que se pueden usar como mecanismo IPC, ¿vale? Los
mapeos se pueden utilizar, o esos archivos mapeados se pueden utilizar como
mecanismo IPC, ¿no? Y esto es así porque los cambios que realiza un
proceso en el archivo mapeado son visibles por todos los procesos que
mapeen dicho archivo en sus espacios de dirección. El uso de archivos
mapeados también presenta inconvenientes, ¿vale? No penséis que
solamente nos aporta inconvenientes la forma tradicional, sino que el uso
de archivos mapeados también nos aporta inconvenientes. Uno de ellos puede
ser que el tamaño de los archivos que se pueden mapear por completo quede
limitado por el tamaño del espacio de direcciones virtuales del proceso,
¿vale? Esto es importante. Ese tamaño suele ser menor de 4 GB en
arquitecturas de 32 bits. Bueno, para los archivos que superan ese tamaño,
el archivo debe ser dividido en trozos cuyo mapeado debe irse alternando en
memoria principal. También ese tamaño del espacio de direcciones
virtuales limita el número de archivos que pueden estar mapeados total o
parcialmente simultáneamente en memoria. ¿Vale? Entonces, y fijaros en
todos estos contenidos. Las páginas 148 y 149 os aportan más información
sobre este tipo de acceso a los archivos, ¿vale? Pero bueno, yo os voy
poniendo aquí como siempre lo más importante a modo de resumen. Nosotros
estaríamos con otro inconveniente, que es tarjeta. Este inconveniente
estaría relacionado con el uso del mapeo como mecanismo IPC, ¿vale? Al
igual que sucedía con las regiones de memoria compartida, es necesario
utilizar algún mecanismo IPC adicional, ¿vale? Por ejemplo, los
semáforos o las colas de mensaje. Se utilizaría este mecanismo IPC
adicional para sincronizar el acceso de los diferentes procesos al archivo
mapeado, ¿de acuerdo? El mapeo de archivos. ¿Puede ser? Puede ser
utilizado tanto por el núcleo como por los procesos. Muy importante,
¿vale? Os lo pongo aquí, muy de amarillo para que lo tengáis. En cuenta,
ese mapeo se puede utilizar tanto por el núcleo como por los procesos.
Bien, en los sistemas operativos basados en UNIX, un proceso para mapear un
archivo en memoria, primero debería invocar la llamada al sistema open
para abrir ese archivo y así obtener su descriptor FD. ¿De acuerdo?
Después debería invocar a la llamada al sistema mmap, que tendría esta
sintaxis que veis aquí. Sería la llamada al sistema mmap y en paréntesis
introduciríamos una serie de argumentos. Tendríamos argumento div 0,
long, prot, int, FD e inicio. ¿Vale? Entonces, ¿de acuerdo? Vemos que
tenemos seis argumentos para esa llamada al sistema mmap. Vamos a describir
ahora cada uno de ellos. El argumento div v0 sería una recomendación para
el núcleo sobre la dirección virtual de comienzo de la región del
espacio de direcciones del proceso. ¿Vale? Donde se va a mapear el
archivo. Sería pues la dirección que recomienda o que se recomienda al
núcleo para mapear el archivo. Lo que se recomienda es configurarlo a 0
para que sea el núcleo el que elija la dirección que considere más
oportuna. Es decir, si nosotros no le recomendamos al núcleo ninguna
dirección, tendremos que introducir en ese argumento el valor 0 y de esa
forma será el núcleo el que eligiese la dirección más oportuna. Luego
veremos que tenemos el argumento long, que es la longitud de la región en
bytes. Si long no es un múltiplo del tamaño de una página SP, entonces
se redondearía el múltiplo mayor más próximo. El argumento prot
permitiría establecer los permisos de acceso a la región. Esa sería su
función. Se implementaría como una combinación de las siguientes
constantes, prot read y prot write, que es escribir. Y por último, prot
execute, que es ejecutar. Entonces sería una combinación de esas
constantes, lo que podríamos introducir en prot. Podría ser 1, 2... 3...
o ninguno, ¿de acuerdo? Y el argumento int sería un conjunto de
indicadores que permiten especificar las características de ese mapeado.
Os vienen aquí los más característicos, que son map-shared y
map-private, ¿de acuerdo? Entonces, el map-shared establecería que el
mapeado del archivo sea de tipo compartido, ¿de acuerdo? Esto significa...
que las operaciones que realiza el proceso sobre un archivo pueden ser
visualizadas por los procesos que mapean ese archivo, ¿vale? Luego, el
map-private establece que el mapeado del archivo sea de tipo privado, ¿de
acuerdo? De esta manera... las modificaciones que realiza el proceso sobre
el archivo no pueden ser visualizadas por los procesos que mapeen este
archivo. En el primer caso sí podrían ser visualizadas y en el segundo
caso no podrían ser visualizadas. El argumento FD sería el descriptor del
archivo. Todo eso lo encontráis en la página 149 y página 150. Por
último, el otro parámetro que nos quedaba, que era el parámetro inicio,
indicaría el byte del archivo a partir del cual se comenzará a mapear. Si
se ejecuta con éxito, la llamada al sistema MMAP que estamos viendo
devuelve en la variable PDIRV, que es la salida, la dirección virtual de
comienzo de la región. ¿No? Y crearía una correspondencia byte a byte
entre el rango de bytes que vemos aquí. Inicio, coma, inicio más la
longitud menos uno. Ese sería el rango entre el cual se crearía una
correspondencia byte a byte. El archivo sería el que tiene el descriptor
FD y la región del proceso situada en el rango de direcciones virtuales se
colocaría en este rango de aquí. PDIRV, coma, PDIRV más long menos uno.
¿Vale? En caso de que la llamada al sistema se ejecutase con error,
devolvería el valor menos uno. Esto es lo que se suele hacer de manera
habitual y lo que vamos viendo a lo largo de la asignatura en todos los
temas. Para eliminar el mapeo de un archivo en el espacio de direcciones
virtuales de un proceso, se debería invocar la llamada al sistema MonMap,
¿vale? A la cual introducimos dos argumentos. El argumento PDIRV y el
argumento LONG. ¿De acuerdo? Si se ejecuta con éxito esta última llamada
al sistema que os acabo de decir, se devolvería el valor C. Y si se
produjese algún error, se devolvería el valor menos uno. ¿Vale? Para
entender todo esto de una manera práctica, podéis echarle un vistazo al
ejemplo 4.2 que empieza en la página 150 y continúa a lo largo de la
página. La página 151 y página 152. Ahí tenéis un ejemplo práctico de
todo lo visto en el apartado de mapeado de archivos en memoria. ¿De
acuerdo? Entonces ahora pasaríamos ya a la página 152, donde nos
encontramos con el apartado 4.2.3 que se titula Estructuras de datos
gestionadas por el núcleo. Asociadas al espacio de direcciones virtuales
de un proceso. ¿De acuerdo? Bien. El núcleo tiene diferentes estructuras
para gestionar el espacio de direcciones de un proceso. Eso ya lo sabéis
de lecturas que habéis dado al libro en anteriores ocasiones. El nombre y
la información que está contenida en esas estructuras dependerá de cada
sistema operativo, ¿de acuerdo? Lo normal es que a cada región existente
se le asocie una estructura, ¿vale? Por ejemplo, E1, que contiene los
siguientes datos. La dirección actual base, el tamaño, los permisos de
acceso y un puntero a la tabla de página, ¿vale? Además, lo normal es
que exista una estructura que vamos a denominar E2 que contenga
información sobre el número de regiones existentes, ¿no? Además,
también podría contener el tamaño total y la localización de las
estructuras E1 asociadas a las regiones, ¿de acuerdo? En la entrada
asociada al proceso en la tabla de procesos se suele mantener un puntero a
su estructura E2. Tenéis un ejemplo de todo esto en la página 152, el
ejemplo 4.3, ¿vale? Bien, deciros que la implementación del espacio de
direcciones virtuales que realiza el sistema operativo Solaris en concreto
está basada en la arquitectura VM, ¿vale? VM significa memoria virtual.
Entonces, sabiendo esto, que sepáis que a partir de aquí los ejemplos que
vais a tener que ir mirando vosotros se detienen en el sistema operativo
Solaris, ¿de acuerdo? Entonces, le echéis un vistazo de nuevo a este
ejemplo 4.3 y ahí veríais la aplicación que tiene el apartado 4.2.3
Entonces, ese ejemplo 4.3 empezaría en la página 152, continuaría en la
página 153 Página 154 y terminaría en la página 155, ¿vale?
Englobaría todas esas figuras que veis ahí. Figura 4-3 y figura 4-4.
Pasaríamos ahora a ver el apartado 4-2-4 de la página 155 que tiene por
título Memoria Anónima, ¿de acuerdo? En primer lugar una definición de
lo que es una página anónima que sería una página que antes de su
creación no dispone de un almacenamiento persistente de respaldo en
memoria secundaria, ¿vale? Estas páginas son utilizadas por ejemplo en la
región de datos no inicializados, el montículo y la región de pila,
¿vale? Todo esto lo vimos anteriormente. También son utilizadas en las
regiones asociadas a archivos mapeados en memoria con el indicador map. Y
este es el caso, por ejemplo, de la región de datos inicializados, ¿vale?
Una página anónima solo se crea, esto es importante, solo se crea cuando
se accede por primera vez a ella durante una operación de escritura,
¿vale? Durante el tratamiento del fallo de página correspondiente es
cuando se le asigna un marco de memoria principal, ¿vale? Se
inicializaría también el marco con ceros con la copia del contenido de
otra página y por último se le asignaría espacio en el área de
intercambio, ¿vale? Al conjunto de páginas anónimas utilizadas por un
proceso Es lo que sí que se denomina ya memoria anónima del proceso,
¿vale? Entonces, el apartado en primer lugar nos define lo que es una
página anónima y ahora nos dice que al conjunto de páginas anónimas es
a lo que se denomina memoria anónima del proceso. ¿De acuerdo? La memoria
anónima de ese proceso se asigna por regiones del espacio de direcciones
virtuales mediante el uso de diferentes estructuras de datos y también
deciros que el núcleo manipula estas estructuras mediante el uso de
funciones. ¿De acuerdo? El nombre y el contenido de las estructuras de
datos que implementan la memoria anónima... ...también el nombre y
también la definición de las funciones del núcleo que operan sobre dicha
memoria dependen de cada sistema operativo basado en units, ¿vale? Tenéis
ahí el ejemplo 4.4 en la página 156 y también es un ejemplo de lo que
hace en concreto el sistema operativo solar. ¿Veis ahí que os aparece en
la figura 4.5 las estructuras de datos que utiliza Solaris para describir
las páginas anónimas de un segmento de tipo sec barra baja vl, ¿no?
Tenéis ahí el esquema de esas estructuras, podéis echarle un vistazo y
así por lo menos veis cómo trabaja un sistema operativo en concreto.
¿Vale? Nosotros no nos vamos a parar en clase a ver estos ejemplos ya que
son ejemplos... Sobre un sistema operativo y sobre otro tipo de sistema
operativo se trabajaría de manera diferente. Entonces esto es para
acercaros de manera real como trabaja un modelo. Entonces eso, le echéis
un vistazo al ejemplo 4.4. Ahora en el apartado 4.2.5 de la página 157
vamos a explicar lo que es la memoria compartida. Una región de memoria
compartida sería un mecanismo IPC que permite compartir datos entre
distintos procesos. Para que un proceso pueda acceder a esos datos debe
mapear la región dentro de su espacio de direcciones virtuales. Ya vimos
el ejemplo 4.4. En la sección 3.5.1 al describir los mecanismos IPC del
System 5 que las llamadas al sistema que debe invocar un proceso para crear
y poder utilizar la región de memoria compartida estaban ahí. Entonces
también comentamos que el núcleo mantiene una tabla con una entrada por
cada mecanismo IPC del tipo de memoria compartida que existan en el
sistema. Es decir, cada tabla contendrá varias entradas con una por cada
mecanismo IPC. Aparte de esa tabla global el núcleo mantendrá diferentes
estructuras de datos. para implementar las reacciones de memoria
compartida. Marcar aquí como muy importante que el nombre y el contenido
de esas estructuras y de datos dependerán, como siempre, de cada sistema
operativo basado en UNIX. Os recomiendo que le echéis un vistazo al
ejemplo 4.5 que veis ahí en esa página 157 que de nuevo se detendrá en
el sistema operativo Solaris. ¿De acuerdo? Entonces, de esa manera,
volvéis a ver cómo trabaja el Solaris para manejar la memoria compartida.
¿Vale? Veis en la figura 4.6 de nuevo un esquema de las estructuras de
datos que utiliza ese sistema operativo para implementar el recurso IPC del
tipo de memoria compartida. En el apartado 4.2.6 veremos las operaciones
que se hacen sobre el espacio de direcciones virtuales de un determinado
proceso. ¿Vale? Sobre el espacio de direcciones virtuales de un proceso el
núcleo puede realizar diferentes operaciones. ¿Vale? Esas operaciones se
pueden agrupar en dos grandes grupos que os voy a mencionar ahora. ¿Vale?
Por un lado, uno de los grupos, lo podemos denominar operaciones que
afectan a todo el espacio de direcciones de un proceso. ¿De acuerdo? Por
ejemplo, la creación de un nuevo espacio de direcciones o la duplicación,
eliminación... de un espacio de direcciones ya existente, ¿vale? Luego
otro grupo en el que se pueden englobar esas operaciones podría ser
operaciones que afectan a una región o segmento del espacio de direcciones
de un proceso. Por ejemplo podríamos introducir ahí la creación de una
nueva región, la eliminación de una región o la configuración y la
comprobación de los permisos de acceso a una región, ¿vale? Esos serían
varios ejemplos de operaciones que podemos encuadrar dentro de ese gran
grupo que se llama operaciones que afectan a una región o segmento del
espacio de direcciones de un proceso, ¿vale? El otro grupo lo tenéis
aquí. Cada subunit define qué operaciones o respectividades de
direcciones soporta y cómo las implementa, ¿de acuerdo? Entonces esta
decisión también depende como siempre del sistema operativo en cuestión,
¿de acuerdo? En el ejemplo 4.6 que veis en esa página 159 os habla de
nuevo de cómo trabaja el sistema operativo Solaris para manejar este tipo
de operaciones. Entonces le echáis un vistazo y veis de manera, real,
cómo trabaja Solaris. Pasaríamos ahora a la página 160 y en esta página
vamos a ver el apartado 4.2.7 que nos habla de la creación en el espacio
de direcciones virtuales de un proceso, ¿vale? Una de las tareas
principales que realiza el núcleo durante... La llamada sistema fork es
eso, la creación del espacio de direcciones virtuales del proceso hijo.
Esa implementación depende de cada sistema operativo basado en UNIX.
Aunque la manera general de hacerlo sería decir que la creación del
espacio de direcciones virtuales del proceso hijo se realiza duplicando las
estructuras de datos asociadas al espacio de direcciones virtuales del
proceso padre. Por el contrario, las páginas del proceso padre no son
inicialmente duplicadas en memoria durante el tratamiento de esa llamada
sistema fork, ya que así se ahorra un gasto en memoria principal y se
disminuye la sobrecarga. Esto lo voy a poner aquí. En color rojo para que
lo veáis como una especie de ventaja. Ahorrar memoria principal y
disminuir sobrecarga. Lo voy a poner aquí, que serían ventajas. Las
páginas que hayan sido asociadas a la región de código del proceso padre
o las regiones de código de las librerías compartidas son de solo
lectura. Muy importante esto. De solo lectura. Y pueden ser compartidas por
el proceso padre y el proceso hijo. Las pueden ir intercambiando entre los
dos. ¿Vale? Son de solo lectura y pueden ser compartidas por el proceso
padre y el proceso hijo. Deciros también que son compartidas... También
las páginas de las regiones de memoria compartida y las regiones asociadas
a archivos mapeados del tipo map-shared que vimos antes. ¿Vale? Estas
páginas también serían compartidas. Tenéis ahí en la página 160 el
ejemplo 4.7 que de nuevo se vuelve a basar en el sistema Solari. ¿De
acuerdo? Bueno, más en concreto ese ejemplo os habla del tratamiento que
Solari se hace de una llamada al sistema fork. ¿Vale? Os da tres pasos que
son los que se tienen que llevar a cabo para que esa llamada al sistema se
ejecute correctamente. ¿Vale? Entonces digamos que el ejemplo 4.7 os
describe la llamada al sistema fork. ¿Cómo se puede trabajar el sistema
fork? Y hasta aquí sería todo lo referente a la primera parte de este
tema 4. ¿Vale? Entonces si queréis podéis parar aquí la clase y volver
a empezar el tema para afianzar bien los conceptos de esa primera parte.
¿Vale? Una vez llegados aquí vamos a ver la segunda parte del tema en la
cual vamos a ver la traducción de direcciones virtuales a direcciones
físicas. ¿Vale? Realizada en este tipo de sistemas operativos que están
basados. Para empezar vamos a ver el apartado 4.3.1 que nos habla de las
tablas de páginas y las MMU. ¿De acuerdo? Una de las principales tareas
que es necesario realizar en la implementación de la técnica de gestión
de memoria mediante demanda de página, ¿qué sería? Pues sería la
traducción de direcciones virtuales a direcciones físicas. ¿Vale? Para
hacer esta traducción se utilizan dos elementos. ¿De acuerdo? Los tenéis
en la página 161 y página 162, 163, 164 y 165. Ahora vamos a ir
definiéndolos de cada manera. La tabla de página sería una estructura de
datos que contiene una entrada por cada página existente en un espacio de
direcciones virtuales. ¿De acuerdo? El tamaño de una entrada. Suele ser
de 32 bits o de 64 bits que se descomponen en diferentes campos. ¿Vale?
Esos campos serían el número, orden, tamaño y contenido de los campos
vendría determinado por la arquitectura del computador. ¿Vale? Es decir,
tendríamos que cada entrada sería de 32 bits o 64 bits que se descomponen
en diferentes campos y el número, orden, tamaño y contenido de esos
campos vendría determinado por... ...la arquitectura del computador que se
corresponda, ¿no? Ahora sí, vamos a pasar a definir esos campos o el
nombre de esos campos y serían los siguientes. En los campos presentes,
habitualmente en una entrada de una tabla de páginas, se encuentran los
siguientes, ¿no? Bien. Tendríamos el número de marco de página...
¿Vale? Que contendría el número de marco J, de número principal, donde
se encuentra almacenada esa página I. Luego la validez o presencia, ¿de
acuerdo? Este campo constaría de un único bit, esto marca algo muy
importante, un único bit, la validez, que podríamos llamar V. Y se activa
si la página I está cargada en el marco J. ¿Vale? Si la página I la
tenemos cargada en el marco J, entonces ese bit V se activaría. Si esa
página no estuviese actualmente en el espacio de direcciones del proceso o
no está cargada en el número principal, ese bit estaría desactivado.
Luego otro campo serían los bits de protección, ¿no? La forma más
simple consta de un único bit. También, como el caso anterior, que en
función de su valor indica si la página es de solo lectura o de
lectura-escritura. Entonces, mediante un solo bit diríamos si la página
es de solo lectura o si por el contrario es de lectura-escritura. Otro
campo sería referenciado, ¿vale? También sería un único bit, ¿de
acuerdo? Vamos a ir poniendo en rojo los campos que contienen un único
bit. En este caso... Denominado R, que se activa cuando la página I es
referenciada por una dirección virtual. ¿Vale? Este bit suele ser
consultado para decidir qué página puede ser reemplazada. No importa.
Otro campo sería... modificada. Este campo también consta de un único
bit denominado M y se activa cuando la página I es modificada en una
operación de lectura. Este no tiene pérdida. Cuando en una operación de
lectura modificamos una página el bit M se activaría. La activación de
este bit indica al núcleo que debe copiar la página en memoria secundaria
antes de reemplazarla. Esas serían las tareas que debe hacer el núcleo
cuando se encuentra con el bit M activado. Cuanto mayor sea el espacio de
direcciones virtuales de un proceso mayor será el tamaño de su tabla de
páginas y más espacio de memoria principal consumirá. Para ahorrar
memoria algunas arquitecturas soportan el uso de tablas de páginas.
También existen algunas arquitecturas que trabajan con tablas de páginas
invertidas. En un determinado instante de tiempo en la memoria del núcleo
existen cargadas varias tablas de páginas. Lo normal es que exista una
única tabla de páginas para describir las páginas del espacio de
direcciones del núcleo y una o más tablas para describir las páginas del
espacio de direcciones de un proceso. En algunos sistemas operativos se
asocian tablas de páginas por región. Entonces en ese caso existiría una
tabla de página asociada a cada región. Bien, al final de la página 161,
veis que os aparece el otro elemento que se utiliza para realizar la
traducción de direcciones virtuales a direcciones físicas, ¿no? Este
elemento se denomina MMU, ¿de acuerdo? El MMU es un componente hardware,
¿vale?, que se encarga de realizar la traducción de una dirección
virtual en una dirección física. Para poder realizar esa traducción, en
un registro de la MMU se carga la dirección física de comienzo, la tabla
de páginas del proceso en ejecución, ¿no? Y además se cargaría
también en el TLB de la MMU una copia de un conjunto de entradas de dicha
tabla de páginas, ¿de acuerdo? Bien, la traducción de direcciones
requiere una colaboración entre el subsistema de gestión de memoria del
núcleo y la MMU. Entonces, eso es marcarlo como importante para que
siempre tengáis en la cabeza que existe esa colaboración a la hora de
realizar una traducción. El subsistema de gestión de memoria se
encargaría de una determinada tarea y, por otro lado, la MMU se
encargaría de otra determinada tarea. Vamos a ver qué hace cada uno de
ellos. Por un lado, el sistema de gestión de memoria se encarga de asignar
espacio, configurar y actualizar. Por otro lado, el sistema de gestión de
memoria se encargaría de actualizar y actualizar las tablas de páginas,
¿vale? Y además... También se encargaría de cargar los registros y el
TLB de la MMU cada vez que se produce un cambio de contexto. Por último,
también se encargaría de atender las excepciones generadas por la MMU.
¿De acuerdo? Entonces, esto que os pongo aquí como número 1 serían las
tareas del subsistema de gestión de memoria. Que como colabora con la MMU,
deberá compaginar esas tareas con las que realiza la MMU. Que son las
siguientes. La MMU se encargaría de comprobar la validez de los accesos,
generar una excepción si el acceso no fuera válido, ¿vale? Traducir las
direcciones virtuales a direcciones físicas y por último activar los bits
referenciada o y modificada. ¿Vale? Que son los campos que vimos
anteriormente. Con el objetivo de ahorrar espacio de memoria principal, los
sistemas operativos basados en UNIX suelen trabajar con tablas de páginas
paginadas. ¿Vale? El número de niveles de paginación utilizados es
fijado por cada sistema operativo basado en UNIX en función de su
arquitectura. ¿De acuerdo? Entonces, de nuevo vuelvo a depender del
sistema operativo y de la arquitectura del computador en concreto. Podéis
ver para entender todos estos conceptos de tablas de páginas paginadas. Si
en el menú el ejemplo 4.8 que encontráis en la página 163, ¿vale? Como
siempre deciros que podéis encontraros ahí más información, pero yo
aquí os pongo la información más relevante y la que a modo de resumen
nos puede servir para... memorizar mejor estos contenidos. El ejemplo 4-8
vuelve a basarse en el sistema Solaris. ¿De acuerdo? Entonces, veréis
ahí varios ejemplos de usos de tablas de páginas, etc. ¿Vale? Veis ahí
la figura 4-7 que va asociada al ejemplo 4-8, ¿vale? Que por ejemplo son
distintas tablas de páginas paginadas de 4 niveles soportadas en
arquitectura de 64 bits de AMD. ¿De acuerdo? También deciros que el
núcleo para gestionar las tablas de páginas de los distintos niveles y la
MMU utiliza diferentes estructuras de datos y funciones. Y como siempre, el
nombre, definición e implementación. Dependen de cada sistema operativo y
de la arquitectura del computador donde se ejecute. ¿Vale? Veis ahí el
ejemplo 4-9 que os hablaría en este caso de MMU y siempre hablando del
sistema Solaris. ¿Vale? Ese ejemplo 4-9 estaría en la página 164 y 165.
¿De acuerdo? Bien, y ahora para acabar esta frase de hoy, vamos a ver el
apartado 4.3.2 que habla sobre el tratamiento de los fallos de página.
¿De acuerdo? La EMU, durante el proceso de traducción de una dirección
virtual en una dirección física, realiza varias operaciones o
comprobaciones en orden secuencial. ¿Vale? Si el resultado de una
comprobación fuera satisfactorio, una comprobación no satisfactoria,
generaría una excepción denominada fallo de página. ¿Vale? Y ese fallo
de página es atendido por el núcleo. Que sepáis que existen dos posibles
tipos de fallos de página. ¿Vale? Uno sería el fallo de validez y otro
sería el fallo de protección. ¿De acuerdo? El fallo de validez se
traduce por una dirección virtual referencia a una página I cuya entrada
asociada en la tabla de páginas tiene el bit de validez desactivado. ¿De
acuerdo? Es decir, el bit que vimos antes estaría a cero. Dicho bit se
encuentra desactivado si la página I no está cargada en un marco J de
memoria principal o también si la página no pertenece al espacio de
direcciones virtuales del proceso. ¿Vale? Luego, el otro tipo de fallo de
página que decíamos que se denominaba fallo de protección se produciría
si la operación tanto de lectura, de escritura o de ejecución que se
desea realizar sobre la página I que ha sido referenciada por la
dirección virtual, no está autorizada por los permisos establecidos en su
entrada de la tabla de páginas. Entonces, si se produce esa operación y
no está autorizada en los permisos que se han establecido en la entrada de
la tabla de páginas, se produciría el fallo de protección, que recordad
que es un fallo de página. La implementación del tratamiento de los
fallos de página depende, como siempre, de cada sistema operativo basado
en UNIX. Aunque de forma general se puede afirmar que el núcleo para
tratar las excepciones producidas por la NMU ejecuta siempre un manejador
de fallos de página. Ese manejador realiza diferentes tareas en función
del tipo de fallo de página. Ese es el que realiza las diferentes tareas
dependiendo de qué tipo de fallo de página se esté produciendo. Por
ejemplo, en la página 165 de la tabla de páginas, el ejemplo 4.10 está
basado en el sistema Solaris. Este sistema Solaris es el que se va a tomar
como referencia para explicar todos los conceptos. teóricos de una manera
un poco más práctica y que veis como se utiliza por un sistema operativo
en la realidad ¿vale? tenéis el ejemplo en la página 165 continuando y
finalizando en la página 166 ¿de acuerdo? bien, y ya en la siguiente
clase será donde veremos que existe una manera de gestionar la memoria
física ¿vale? que es lo que denominábamos tercera parte y también
veremos la cuarta parte del tema ¿vale? que como vimos al principio de las
diapositivas esta cuarta parte trataría sobre la gestión de la memoria
perteneciente al núcleo ¿de acuerdo? entonces lo dejamos aquí, en esta
primera clase del tema 4 hemos visto las dos primeras partes del tema y en
la siguiente clase veremos la parte 3 y la parte 4 y os recomendaré algún
ejercicio para que hagáis sobre estos contenidos teóricos ¿de acuerdo?
entonces nada más y me despido hasta la siguiente video tutorial un saludo