forked from gcastigl/SO2C2011TP2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
txt inf
- Loading branch information
horacio.gomez
committed
Nov 29, 2011
1 parent
3cf2a40
commit c8c8b5f
Showing
1 changed file
with
51 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,51 @@ | ||
PIPES | ||
|
||
El principal obstaculo de la implentación fue decidir donde escribir el mensaje enviado por el escritor a los receptores. Como primera alternativa se pensó en guardarlo en el mismo fifo, dado que es un file y puede tener contenido. Si bién dicha implementación es sencilla, hacía que la trasmisión del mensaje sea extremadamente lenta. Para superar esto se optó por guardar el mensaje en una zona de memoría especialmente destinada para esto. La principal limitación es que se pueden abrir sólo un número fijo de fifos al mismo tiempo. Al estar el mensaje en memoria, la transmisión es mucho más rapida. | ||
Otro problema que traen los fifos es que deben ser bloqueados tanto para lectura como para escritura. Se utilizaron los semaforos dados en el ejemplo mtask1 de la cátedra para esto. | ||
Se crearon los comandos mkfifo para crear el fifo y pitest para realizar pruebas cobre el mismo. | ||
|
||
El comando pitest crea el fifo con nombre “test.pipe” si no existe, en caso contrario se conecta al mismo. Y bloquea al proceso para el modo en que se conectó al pipe. | ||
Pitest w: modo escritura. | ||
Pitest r: modo lectura. | ||
NOTA: ambos procesos deben estar en el mismo directorio dado que el fifo se crea en el directorio actual. | ||
|
||
CACHE | ||
Gran parte de la implementación del cache fue realizada (y detallada) durante el tp anterior. Sin embargo se mejoraron algunos aspectos en el algoritmo de reemplazo de sectores (Least Recently Used). Antes se tenía un contador por cada sector del disco y cada vez que era accedido ya sea para lectura o escritura, era incrementado. El problema de esto es que sectores eran ordenados por cantidad de accesos y podían persistir en cache por mucho tiempo hasta que otro file tuviera mayor o igual cantidad. Esto traía el problema de que los sectores más accedidos nunca eran removidos del cache. En la nueva implementación se optó por agregar un contador de edad en cache para que si un sector cacheado supera la edad tope, se elimine. | ||
|
||
FILE SYSTEM | ||
|
||
Se implementó el manejo de inodos por medio de un bitmap, por sobre el bitmap de contenidos que ya existía, lo que permitió la implementación como mv y rm. | ||
|
||
Se agregaron los comandos standard de linux que faltaban en el tp anterior. | ||
Mv desde hasta: mueve el archivo desde a hasta. | ||
Rm nombre: elimina el archivo nombre. | ||
cp desde hasta: copia el archivo desde a hasta. | ||
Ls: se mejoró la forma de mostrar archivos, agregando colores y caracteres especiales para diferenciar los tipos (ej: link@ ) | ||
|
||
PROCESOS / SCHEDULING | ||
|
||
Se le agregaron a los procesos una lista de file descriptors para mantener un registro de los archivos abiertos por el mismo. | ||
Cuando un proceso se bloquea se le setea un flag para saber a causa de qué se bloqueo. Puede ser bloqueado para input, fifos, wait-child, wait-semaphore. | ||
Gracias a estos cambios se pudo remover el estado de busy-waiting en todos los procesos, en especial, la shell que permanece bloqueada por input. | ||
|
||
|
||
PAGING | ||
|
||
Virtual Address | ||
|
||
Se implementaron directorios y tablas de páginas. Se dividió la memoria de a 4K (0x1000). Cuando se inicializa paging se crea un heap de kernel en la direción 0xC00000000. | ||
En una primera implementación los procesos creaban sus stacks con malloc, estro traía el problema de que el stack estaba dentro del heap, lo que limitaba mucho la memoria. Se optó por mover los stacks de los procesos a una zona de memoria dedicada para esto, cerca del final del address space. De esta manera al tener el heap arriba que avanza en forma decreciente y el stack abajo que avanza en forma creciente, la memoria queda mucho más organizada. | ||
Cada vez que se crea un proceso se alocan dos páginas de memoria. No obstante adelantando que el proceso seguramente pida más páginas los nuevos procesos no son creados inmediatamente después sinó que se dejan un número de páginas en blanco entre los dos. | ||
|
||
Physical Address | ||
|
||
Cuando hablamos de páginas, estamos hablando de direcciones virtuales de memoria, una página puede querar ir a la dirección de memoria 0x8000000 (128MB) pero para que esto funcione en nuestra máquina virtual que le dimos 16MB de memoría necesita hacer un mapeo de la misma. Los bloques reales de memoria los llamamos frames y son manejados mediante un bitmap p | ||
|
||
Heap | ||
|
||
El algoritmo que maneja el heap utiliza dos conceptos: blocks & holes. Llamamos blocks a aquellas zonas de memoria que contienen información (mallocs no liberados) y holes a las zonas de memoria libre. En un principio la memoria del heap es un gran hole. | ||
Por cada hole existe un indice en la tabla ordenada de holes. El orden es necesario porque luego buscaremos los espacios mínimos a ocupar a la hora de hacer mallocs. | ||
Tantos los blocks como los holes tienen un header y un footer para guadar información de la porción de memoría a la cual pertenecen. | ||
A medida que se hacen mallocs en el sistema, el heap puede ir quedando chico, para poder detectar esto se agregaron una serie de asertions para poder expandir las páginas reservadas para el heap. También se agregó la posibilidad de que se contraiga en caso de que se libere la misma. | ||
|
||
|