pequeñas dudas sobre la escritura en memoria

[nicolasvultaggio]

Buenas! como bien nos marca el enunciado, la mmu debe realizar una traducción de la dirección lógica a la dirección física, eso no hay ninguna duda. El tema es en los casos en los que lo que se va a escribir ocupe más de una página:

Es importante tener en cuenta en este punto que una Dirección Lógica va a pertenecer a una página en cuestión, pero el contenido a leer o escribir puede ser que ocupe más de una página, por ejemplo, supongamos que tenemos páginas de 16 bytes cada una y que quedemos escribir el texto: “Cursada de Sistemas Operativos 1c2024”, esto si lo dividimos nos va a quedar ocupando 3 páginas, de manera que lo podemos representar fácilmente de la siguiente manera:

Es trabajo del grupo contemplar y manejar estos casos correctamente.

La MMU es la que se encarga de validar que haya marcos asignados al proceso suficientes para realizar esta escritura? O la MMU simplemente realiza la traducción, solicita a memoria la escritura o lectura, y la memoria es la que informa el error (en caso de que no haya suficientes marcos asignados para escribir) ?

Estos marcos asignados, deben sí o sí estar de forma contigua en memoria? este es el caso de la imagen del ejemplo, pero podría pasar que por ejemplo, los primeros dos marcos sí estén de forma contigua, y que el resto del texto se escriba en otro marco mucho más "lejos"?

[mefederico]

Hola buenas!

La MMU es la que se encarga de validar que haya marcos asignados al proceso suficientes para realizar esta escritura?

La MMU solamente se encarga de las traducciones de direcciones lógicas a direcciones físicas

No hace falta que controlen esos casos, nosotros siempre vamos a hacer resize previamente, por lo que van a tener el espacio suficiente, en el único caso que no lo van a tener es cuando se hace un resize y no hay espacio suficiente en la memoria, donde tienen que lanzar un Out of Memory

Si igualmente quieren controlarlo por comodidad de las pruebas y poder frenar el proceso, podrían en la memoria hacer un Out of Memory de la misma forma.

Estos marcos asignados, deben sí o sí estar de forma contigua en memoria?

No, los marcos no necesariamente van a estar contiguos.

Saludos!

[nicolasvultaggio]

y cuando se hace resize, ese tamaño que viene en la operacion, es un numero entero de marcos?

[iago64]

Buenas! Cómo va?

El tamaño es en bytes.

Saludos.-

[nicolasvultaggio]

pero entonces nosotros tendríamos que traducirlo a un numero entero de marcos, no? porque no tendría sentido por ejemplo que ese tamaño en bytes sean 2 marcos y medio, dado el caso deberíamos asignar 3 marcos no?

[iago64]

Buenas! Cómo va?

Si, uds tienen que hacer esa traducción de bytes a páginas / marcos.

Saludos.-

[nicolasvultaggio]

entonces, por ejemplo, para reducir el tamaño de un proceso, ese numero de bytes viene en negativo?

[mefederico]

Hola buenas!

Citando el enunciado

RESIZE (Tamaño): Solicitará a la Memoria ajustar el tamaño del proceso al tamaño pasado por parámetro. En caso de que la respuesta de la memoria sea Out of Memory, se deberá devolver el contexto de ejecución al Kernel informando de esta situación.

El parámetro pasado es el tamaño que tiene que tomar la memoria así que ese numero es en el que tiene que quedar la memoria.

Si hago RESIZE 10 RESIZE 15

La memoria del proceso debe quedar con un tamaño de 15

si hago RESIZE 10 RESIZE 5

La memoria del proceso debe quedar con un tamaño de 5

Saludos!

[nicolasvultaggio]

AHHH, pense que resize te decía cuantos bytes aumentar o cuantos bytes disminuir en relacion al tamaño actual, perfecto, gracias por la molestia

[nicolasvultaggio]

Estos marcos asignados, deben sí o sí estar de forma contigua en memoria?

No, los marcos no necesariamente van a estar contiguos.

cuando el tamaño de eso que queremos escribir no alcanza en el marco en el que queremos escribir, a partir de donde nos ponemos a buscar marcos nuevos?

a partir de los primeros marcos asignados (inicio del espacio asignado al proceso) hasta el marco donde primeramente escribimos?

o de los marcos asignados restantes que estén DESPUES del marco que ya escribimos, y una vez que no haya marcos siguientes, devolvemos error?

no se si se entiende bien lo que pregunto, existe una prioridad para manejar estos casos?

[mefederico]

Hola!

Ustedes al escribir NO van a buscar marcos nuevos, para eso nosotros vamos a hacer el RESIZE necesario, si pasara que no entra el dato en los marcos previamente asignados es un error en la prueba, si quieren tiren un Out of Memory

Ahora cuando hagan resize y tengan que conseguir nuevos marcos, tienen que buscarlos en cualquier lugar, cualquier marco libre es candidato a ser usado, ustedes pueden buscar de la forma que les parezca más cómoda/optima/primera que funcione/entiendan y va estar bien, no nos metemos en esa implementación

Saludos!

[nicolasvultaggio]

claro, yo no me refiero al momento en que al querer escribir, sucede lo siguiente:

Es importante tener en cuenta en este punto que una Dirección Lógica va a pertenecer a una página en cuestión, pero el contenido a leer o escribir puede ser que ocupe más de una página, por ejemplo, supongamos que tenemos páginas de 16 bytes cada una y que quedemos escribir el texto: “Cursada de Sistemas Operativos 1c2024”, esto si lo dividimos nos va a quedar ocupando 3 páginas, de manera que lo podemos representar fácilmente de la siguiente manera:

entonces eso que escribimos podría esta repartido entre varios marcos, y, como se nos pide manejar esos casos en que los marcos no estén de forma contigua, entiendo que podría pasar lo siguiente

Cuando escribimos "CUR" en el primer marco, sabemos que tenemos que buscar otros marcos para seguir escribiendo, entonces, como se ve en la imagen, siguio escribiendo el resto en el marco 6. Mi pregunta es, si como se ve en la imagen, al buscar mas marcos para escribir, debe buscar los posteriores al marco original (como se ve en la imagen, que se busco el 6), o debería haber seguido escribiendo a partir del marco 0, ya que es el primer marco asignado que tiene en toda la memoria.

[RaniAgus]

¡Buenas! La Memoria en ningún momento debe "buscar marcos para escribir", solamente es una caja boba a la que la CPU le dice "escribime estos n bytes partiendo de esta dirección física" y la Memoria va y lo hace. Si "buscara" a partir de la página 0 cuando se le termina la página, el programa no podría recuperar el texto ya que me quedaría desparramado por cualquier lado.

En el ejemplo que nos diste, la CPU debe escribir en memoria el string "CURSADA SISTEMAS OPERATIVOS 1C 22024" en la dirección lógica 37. Es correcta la forma en la que lo plantean distribuir, ya que luego cuando quiera recuperar el string éste debería estar entre las direcciones lógicas 37 y 73.

Ahora, para llegar a esto, la CPU debe entender que lo que quiere es escribir entre la dirección lógica 37 y la 73, y como el tamaño de página es 10, va a necesitar hacer varias traducciones en Memoria partiendo desde la página 3 hasta la 7 inclusive.

Una vez hechas las 5 traducciones, lo único que va a hacer es pedirle a la Memoria que escriba:

• 3 bytes en la dirección física 37
• 10 bytes en la dirección física 60
• 10 bytes en la dirección física 70
• 10 bytes en la dirección física 90
• 4 bytes en la dirección física 110

Y la Memoria solo va y lo hace.

¿Quedó clara la idea?

Saludos

[nicolasvultaggio]

o sea, no es que pasamos el contenido a escribir y la direccion fisica a la memoria, si no que, es la cpu la que hace este calculo y recien ahí le pide a la memoria todo.

entonces el razonamiento sería: con la dirección lógica y el tamaño de lo que escribimos, el tamaño "logico" total de lo que vamos a escribir, ya que siempre un proceso escribe "lógicamente" de forma contigua, o sea, el proceso "piensa" que sus paginas están de forma contigua, pero la mmu es la que se encarga de partirlos

existe una funcion de la commons que ayude a implementar esta logica para partir? porque que haya desplazamiento complica bastante el determinar la cantidad de traducciones que deben realizarse y cuantos bytes guardar en cada una

[RaniAgus]

que haya desplazamiento complica bastante el determinar la cantidad de traducciones que deben realizarse y cuantos bytes guardar en cada una

No necesariamente. Siguiendo con el ejemplo, a partir de solamente estos datos:

• La primera dirección es la 37
• La última dirección es la 73
• El tamaño de página es 10

Ya deberías poder deducir la cantidad de páginas a leer: desde la 3 hasta la 7, o sea 5

También, para los bytes a escribir ya sabés que el total es 37 (73 - 37 + 1), entonces:

• La primera es lo que te queda de página: 10 - 7 = 3
• Las intermedias son el total de la página: 10
• La última es lo que te falta escribir: 37 - (3 + (5 - 2)*10) = 4

Siendo prolijos van a poder armar un par de funciones que les vayan resolviendo estos cálculos y armar las solicitudes que necesiten 💪🏻

Saludos

[nicolasvultaggio]

sisi, te juro que apenas mande el issue me lo puse a trabajar un poco y se me ocurrio lo mismo que a vos, pero en el momento me pegue un susto barbaro jajaj. Muchas gracias!!!

lo unico, los bytes a escribir no te lo dice ya la instruccion? eso creo que no hace falta calcularlo, o sea es al reves, a partir de la direccion logica inicial y el tamaño de lo que vas a escribir, obtenes la direccion logica final, o me estoy equivocando?

[RaniAgus]

Cierto! Sí, la dirección lógica y el tamaño son dato, la dirección lógica final se puede obtener de ahí

[nicolasvultaggio]

perfecto, muchas gracias!