[Mi-Ram-HQ] Paginación: Que páginas traer a memoria

[jcastagno99]

Buenas, estaba testeando con las pruebas finales cuando me di cuenta de que los reemplazos de paginas no se reflejaban como decia el documento de pruebas, volvi a ver varios issues del tema como el #2183 y tengo algunas preguntas:

Yo hasta ahora me estaba trayendo solo la página que contenia el dato a actualizar, pero viendo el issue entiendo que hay que traer todo, mis dudas va mas a que es el todo y cuando:

1.- La razón es simplemente que tenemos que ser justos con todos los grupos al momento de definir las pruebas (que tienen que ser determinísticas) y dado que no todos tienen armadas las estructuras para traerse solo algunos campos del TCB tienen que traerse el PCB completo. Por el otro lado el identificador de la próxima tarea a ejecutar si es un indicador claro de la siguiente tarea por lo cual no tiene sentido que traigan a memoria todas las tareas.

Tengo 3 casos de actualización/lectura de datos:

•Cuando un tripulante actualiza su estado •Cuando un tripulante pide su proxima tarea (y actualizamos el puntero a la siguiente) •Cuando un tripulante actualiza su ubicación

1) ¿Para los 3 casos debo traer a memoria el TCB entero de cada tripulante? es decir TODAS LAS PAGINAS desde el inicio hasta 21 bytes (que es lo que ocupa el tcb)

2) ¿En que caso tendría que traer el PCB entero? porque en si todo el tiempo que actualizo datos del tripulante me traigo su TCB entero, no hace falta el PCB, ¿o si?

2,2) Cuando yo pido una proxima tarea, solo accedo al puntero a la dir logica de la tarea que esta en el TCB del tripulante, en este caso con esa página sola alcanza? yo habia validado una implementación (la explico en el issue #2202) de tener las tareas separadas en una estructura administrativa (obviamente las tengo tambien en memoria) separadas para saber los tamaños y usar el indice de la dir logica (que tambien esta en memoria) para retornar la tarea desde la estructura administrativa, yo en este caso no leo la tarea de memoria, es necesario que tambien me traiga la pagina de esa tarea? o todas las paginas que tengan las tareas? no me quedo claro

Como dato extra la prueba que estoy corriendo es:

INICIAR_PATOTA 1 PAG_PatotaA.txt 1|1 INICIAR_PATOTA 1 PAG_PatotaB.txt 3|3 INICIAR_PATOTA 1 PAG_PatotaC.txt 5|5 INICIAR_PLANIFICACION

Que es la prueba de paginación del documento: https://docs.google.com/document/d/1rorLRNnwpM9kKxeuHAwM0mmNN20X0Mb20Q-I66y6sdc/edit#

Mis resultados son:

Dump: 20/07/21 17:30:55 Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 1 Pagina: 1 Marco: 2 Estado: 0 Proceso: 2 Pagina: 0 Marco: 3 Estado: 0 Proceso: 2 Pagina: 1

En este caso solo se reemplazan las páginas concretas de los datos.

[jcastagno99]

Actualizo: Leyendo de nuevo la prueba para poder cumplir con:

Al llegar las 3 patotas a Ready, Patota A y Patota B deberían estar en swap, y patota C ocupar la totalidad de los marcos

Para esto deberia traerme todo el PCB cuando se quiere leer un unico dato de un TCB, en este caso: Proceso 1 -> Ocupa 2 paginas, todo su TCB (tiene un unico tripulante) esta en la página 1 Proceso 2 -> Ocupa 2 paginas, todo su TCB (tiene un unico tripulante) esta en la página 1 Proceso 3 -> Ocupa 4 páginas, todo su TCB (tiene un unico tripulante) esta en la página 3

Por lo que al ejecutar con LRU (solo trayendome la totalidad de los TCBS) cuando el proceso 3 llegue a READY memoria queda asi:

Dump: 20/07/21 17:30:55 Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 1 Pagina: 1 Marco: 2 Estado: 0 Proceso: 2 Pagina: 0 Marco: 3 Estado: 0 Proceso: 2 Pagina: 1

(exactamente igual que antes por pura coincidencia), sigue sin cumplir lo que pide la prueba por lo que asumo que entonces me traigo todo el PCB a memoria cada vez que quiera actualizar/leer algun dato? entonces no tiene sentido traer SOLO LOS TCBS

[iago64]

Buenas! Cómo va?

Pregunta del millón, y los datos de las tareas? Porque el punto de "conflicto" que estoy viendo es que estas teniendo en cuenta los PCB, pero no estas mencionando que te traes las páginas para leer las tareas.

Independientemente de eso, cuando terminas de cargar las cosas deberías tener a los datos de la patota A y de la patota B en Swap ya que la patota C casualmente ocupa 4 frames.

Saludos.-

[jcastagno99]

Buenas!

Claro, justo ahí esta mi pregunta, me tengo que traer todo el PCB para leer/escribir algun dato de un TCB? si hago eso, si que me ocuparía el proceso C toda la memoria (pero solo cuando se busque leerlo/escribirlo, porque inicialmente llega primero A, me ocupa 2 frames, luego llega B ocupa otros 2 y luego llega C y se va para Swap)

y la otra era : Las tareas en si no me las estoy trayendo, porque leo la direccion logica de la proxima tarea (la del tcb) y la busco en una estructura administrativa (inicialmente si las guardo en memoria, pero no las leo desde ahi), aun así debería traerme la pagina de la tarea por lo que entiendo, pero ¿La que contenga esa unica tarea? o ¿todas las tareas? -- Todo esto no tienen mucho sentido si directamente en la primer pregunta me tengo que traer TODO EL PCB

No se si se entiende lo que quiero decir.

[iago64]

Buenas!

Ahora si me cierra mas, pero vamos en orden. No hace falta que traigan el PCB, ya que el TCB tiene la dirección lógica de la próxima tarea para ejecutar. Ahora lo que SI tienen que hacer es leer las tareas desde la memoria, las estructuras administrativas son una ayuda para administrar la memoria, no para contener la información.

Saludos.-

[jcastagno99]

Perdón, no me queda claro algo del PCB/TCB. Si no hace falta que me traiga todo el PCB, entonces el proceso C no debería ocupar los 4 frames, el primer frame lo va a ocupar porque yo voy a querer la primer tarea y la primer tarea la voy a guardar en el primer frame (asumo LRU, pero no importa en lo que quiero explicar), despues todo el segundo y tercer frame (y un poco del cuarto) son tareas, como yo no necesito estas tareas ya que solo busco la primera (que esta en el primer frame) a lo sumo el proceso C ocuparia 2 frames, en el que voy a guardar la tarea especifica que quiero (la primera para el caso de que C llegue a Ready) y el frame que tiene todo el TCB (que en este caso esta todo el TCB en la pagina 3 contando desde 0).

Lo de las tareas si me cierra, pero con lo que explico arriba me sigue sin dar lo que se espera en la prueba Sacando cuentas: el proceso me peso 118 bytes -> paginas de 32 bytes, el proceso ocupa 4 paginas (3 enteras y 22 bytes de la cuarta), el TCB (del unico tripulante) son los ultimos 21 bytes que entran en la cuarta pagina, la primer tarea se guarda en la primer pagina (junto con otras tareas, porque serian 4 bytes del PID, 4 bytes de la dir-logica-tareas y 24 bytes de tareas) por lo que seria traerme a memoria solo 2 paginas, la primera y la ultima.

No se si es que me estoy mareando, pero como que no me cierra cuando traerme algunas paginas, cuando traerme todo (perdón por el mucho texto, de nuevo)

[pablov23]

Me sumo a la consulta si no molesta por una duda sobre este mismo tema.

Nuestra solución si trae a Memoria Principal el PCB, ya que a partir del mismo (Que tiene la dirección lógica del inicio de las tareas) vamos obteniendo las demás tareas con del identificador de la tarea de cada TCB (Cómo en el doc de lo nombraba identificador, lo implementamos simplemente como el número de la tarea). Esto requiere que traigamos a memoria todo el bloque de tareas cada vez que necesitemos leer.

¿Está bien esta implementación o la modificamos para que no se utilice el puntero del PCB y sólo se maneje con el del TCB?

Gracias!

[iago64]

Buenas! ¿Cómo va?

@jcastagno99 El proceso C cuando se carga ocupa los 4 frames porque independientemente del algoritmo, va a ir reemplazando los frames de tu memoria principal y en ambos casos como NO tenes iniciada la planificación no deberían estas haciendo nada mas que cargar las cosas. Al momento que inicias la planificación tenes que traerte el frame que tiene el TCB y la tarea, con lo cual salvo el caso donde tengas TCB - Tareas - PCB, no hay chance de que tengas todo en 1 solo frame (ya que TCB = 21 bytes y Tarea = 10 Bytes) (en el caso de las patotas A y B), por otro lado, después al momento de los cambios de tarea, dado cada una dura 5 ciclos de CPU y casualmente es el mismo Quantum para RR, vas a tener que traerte nuevamente el frame que tiene el TCB y el frame de las tareas.

@pablov23 Es un caso borde porque entiendo que ante cada petición estas obligado a traerte todo el proceso a memoria, y que pasaría si en lugar de 4 frames la patota C ocupara por ejemplo 8 frames? como te lo traes?

Saludos.-

[pablov23]

@iago64 Perfecto Damián, gracias por la aclaración. No habíamos contemplado un caso así.

[jcastagno99]

El proceso C cuando se carga ocupa los 4 frames porque independientemente del algoritmo, va a ir reemplazando los frames de tu memoria principal y en ambos casos como NO tenes iniciada la planificación no deberían estas haciendo nada mas que cargar las cosas.

Entonces cuando un proceso llega con INICIAR_PATOTA a Mi-Ram-HQ, yo debo si o si ponerlo en memoria? porque cuando llega el proceso C, toda mi memoria esta llena y yo lo que hacia era mandarlo para SWAP, pero si cuando llega lo que hace es mandar a SWAP a los proceso A y B y se queda en memoria si cumpliria conque:

Al llegar las 3 patotas a Ready, Patota A y Patota B deberían estar en swap, y patota C ocupar la totalidad de los marcos

Y ahí si me cierra el caso. 1-¿Es así?

2- ¿Y entonces cuando quiero actualizar ubicación o actualizar estado de un tripulante, tengo que traerme todo el PCB o solo el TCB?

3-¿Y para proxima tarea, me traigo SOLO la pagina del TCB que tenga la direccion logica a proxima tarea y la pagina que contenga la tarea en si?

Perdón si estoy repreguntando mucho y es re pesado, posta que estoy tratando de entenderlo lo mejor posible.

[iago64]

Buenas! ¿Cómo va?

Pesado es comer lechón en navidad con 30 grados, vos solo estas preguntando y esta perfecto que quieras confirmar las cosas.

1.- Si, todo va a principal y se va bajando a swap cuando no hay mas espacio en principal.

2.- Solo el TCB, el PCB en el estado o la ubicación del tripulante no corta ni pincha.

3.- TCB y Página/s de la tarea en cuestión.

Saludos.-

[jcastagno99]

Perfecto, me cerró todo.

Muchas gracias!! =)

[jcastagno99]

Duro poco la paz(?

Tengo una pregunta sobre cuando yo me traigo todo el TCB a memoria, tiene que ver con el algoritmo LRU, usando este mismo ejemplo:

La primera vez que llegamos al paso 4:

Ejecuta el tripulante de la patota C, reemplazando dos páginas de A

Hasta acá estamos perfecto, el problema es que dice:

Esto continua hasta terminar la patota A

En la primera vuelta, A reemplaza 2 paginas de C, y B reemplaza las otras 2 paginas de C

Luego, C vuelve a ejecutar, lo primero que hace es un Actualizar Estado, por lo que solo se trae su TCB (esta en su página 3, entero)

Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 1 Pagina: 1 Marco: 2 Estado: 0 Proceso: 2 Pagina: 1 Marco: 3 Estado: 0 Proceso: 2 Pagina: 0

Reemplazo la pagina 0 de A que esta bien.

Luego C quiere obtener su proxima tarea

El TCB de su tripulante ya esta en memoria, por lo que le falta traerse la pagina de la tarea en especifico, la primer tarea son 10 bytes, está entera en la primer pagina (8 del PCB + 10 de la tarea < 32 de la primer pagina)

Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 3 Pagina: 0 Marco: 2 Estado: 0 Proceso: 2 Pagina: 1 Marco: 3 Estado: 0 Proceso: 2 Pagina: 0

Reemplaza la pagina 1 del proceso A que tambien esta bien.

El problema arranca porque ahora, vuelve a ejecutar A pero no va a reemplazar las paginas de C, sino que reemplaza las de B A solo reemplaza la de C en la primer vuelta, luego reemplaza la de B Por lo que el ciclo de : A reemplaza C, B reemplaza C, C reemplaza A, solo se cumple al principio, cuando C ocupa toda la memoria Luego el ciclo seria A reemplaza a B, B reemplaza a C, C reemplaza a A y asi. Esta bien esto? según lo que hablamos tendria sentido que sea así creo.

[jcastagno99]

Añado otra pregunta relacionada al tema (y ya que me dieron el visto bueno para seguir preguntado me voy a aprovechar de eso)

Cuando un tripulante termina su ejecución (terminó todas sus tareas) luego desde discordiador me llega un Actualizar el estado a Exit, esto hace que yo me tenga que volver a traer una o varias paginas a memoria (todo el TCB de ese tripulante) para actualizar el estado, por lo que en el caso de prueba anterior, me pasa que cuando A termina su ejecución luego me solicita otro cambio de estado y tambien cambia los resultados esperados.

En ese punto mis frames estan así :

Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 3 Pagina: 0 Marco: 2 Estado: 0 Proceso: 2 Pagina: 1 Marco: 3 Estado: 0 Proceso: 3 Pagina: 1

El proceso 3 en un momento tenia que leer una tarea que estaba partida en 2 paginas, por lo que necesitaba ocupar 3 paginas (1 del tcb, y 2 de la tarea)

Y ahora llega A a decir que termino, sacando el proceso B (porque C uso esos 3 marcos en el instante anterior)

Luego vuelve B y reemplaza uno de los frames de C,

C va a seguir ejecutando, y cuando llega a la tarea C05 necesita 2 paginas, La pagina 1 (la C05 arranca en la pagina 1 offset 26) y la siguiente pagina (pagina 2 que lee hasta 4 bytes) y aca reemplaza la pagina del proceso 1. No cumpliria esto:

C swapea la página de sus tareas por otra página con tareas.

ya despues de esto sigue ejecutando normal, B no swapea mas (que eso esta bien)

Para evitar esto, deberia hacer que A no me vuelva a pedir su pagina para actualizar su estado a Exit. entonces la pregunta se resume en: ¿Cuando un tripulante ejecute su ultima tarea, le paso el estado a exit de una o espero a que discordiador reciba "che esta es su ultima tarea" y me pida que actualice el estado a Exit?

Porque dependiendo de si espero o no ese mensaje, se me cambian los remplazos

[iago64]

Aloha!

Ahí ajustamos la descripción, fuimos un toque escuetos en los resultados, igual esta bien que se fueran alternando en a quien reemplazaban 😄

Respecto al estado, vos antes de sacarlo de EXEC, pedís la tarea, no esta lo mandas a EXIT y lo sacas de memoria, acordate que la memoria solo concibe Ready, Exec y Bloq, en Exit lo limpias 😉

Saludos.-

[jcastagno99]

Perfecto, lo estuve leyendo y me queda mucho mas claro, muchas gracias por todo =) !

[jcastagno99]

Im back, con una pequeña discrepancia en el resultado de las pruebas

No se si esta contemplado, pero hay un punto en el que el proceso C necesita de 3 páginas a la vez en memoria, cuando quiere obtener su tarea C02, dicha tarea esta partida en 2 paginas, la posicion inicial de la tarea es 28 bytes (8 de pcb + 10 de C00 + 10 C01) por lo que en la primer pagina tiene 4 bytes y luego en la segunda pagina tiene los 6 restantes Como estuvimos hablando, cuando un tripulante pide su tarea, se trae a memoria todo su TCB (que esta en la pagina 3 [arrancando de 0]) por lo que me suena bien que ocupe 3 paginas, voy a dejar el estado del dump antes y despues de la solicitud de esta tarea :

Antes :

Dump: 23/07/21 17:22:36 Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 1 Pagina: 1 Marco: 2 Estado: 0 Proceso: 2 Pagina: 1 Marco: 3 Estado: 0 Proceso: 2 Pagina: 0

El proceso 3 habia solicitado cambiar su estado, por lo que se trajo a memoria su TCB (pagina 3)

Luego de la solicitud de la tarea partida :

Dump: 23/07/21 17:22:36 Marco: 0 Estado: 0 Proceso: 3 Pagina: 3 Marco: 1 Estado: 0 Proceso: 3 Pagina: 0 Marco: 2 Estado: 0 Proceso: 2 Pagina: 1 Marco: 3 Estado: 0 Proceso: 3 Pagina: 1

Siento que estan bien los reemplazos, aca la duda es que los resultados esperados del documento de pruebas dice que se van reemplazando de 2 en 2 hasta que finaliza A, pero acá C reemplaza 3 ¿Esta bien esto?

[iago64]

Buenas! Cómo va?

Justo el caso que uds plantean es un poco diferente porque están cargando las cosas en otro orden con lo cual es posible que tengamos este caso borde y no estaría mal (siempre y cuando lo puedan mostrar claramente en los logs 😉

Saludos.-

[jcastagno99]

Disculpa la demora, perfecto, todo claro entonces Gracias!