Merge pull request #4 from themultiplexer/hw3

hw3

hw3/README.md

@@ -26,7 +26,7 @@ You find all Files for your simulation homework in the `simuN/` directory.
 
 **IMPORTANT**: This time, there is no possibility to give more
 explanations/comments  AFTER the Code Review. You have to give all the asked
-explanations and comments (in German or English) before the code review.
+explanations and comments before the code review.
 
 The code review starts after the deadline, so you have enough time to extend
 your answers, if your Pull-Request was quite early. After the deadline there

hw3/simu1/ANSWERS.md

@@ -0,0 +1,21 @@
+# Simulation 1 - Antworten
+
+1. Das letzte Segment liegt auf der dezimalen (virtuellen) Adresse 929. Damit dieses Segment in den Adressraum passt, muss dieser mindestens ein Limit von **930** haben.
+
+2. Der physikalische Adressraum ist 16kB groß und das Limit beträgt 100. 16384 - 100 = 16284
+
+3. Bei einer Vergrößerung des **Adressraums** (z.B. `-a 2k`) nimmt die Zahl der Segmentation-Fehler zu, da das Programm die Adressen aus einer **größeren Spanne** auswählt, das **Limit** der validen Adressen sich jedoch nicht ändert. Vergrößern wir jedoch die Größe des **physikalischen Speichers**, ändert sich nichts am Ergebnis - die Größe des verfügbaren Speichers hat nämlich *keinen Einfluss* darauf, aus welcher **Reichweite** das Programm Adressen auswählt bzw. bis zu welchem Limit Adressen **valide** sind.
+
+4.
+VA | Seg. Vio.?
+---|---
+0|no
+1|yes
+2|no
+3|no
+4|yes
+5|yes
+6|yes
+7|no
+8|yes
+9|no

hw3/simu2/ANSWERS.md

@@ -0,0 +1,82 @@
+## Warmup
+
+| VA Number | Virtual Adress     | Physical Adress     | Valid |
+| --------- | :----------------- | ------------------- | ----- |
+| VA  0     | 0x11  --> 0010001  | 000010001 --> 0x011 | YES   |
+| VA  1     | 0x6c  --> 1101100  | 111101100 --> 0x1ec | YES   |
+| VA  2     | 0x61  --> 1100001  | 111100001 --> 0x1e1 | NO    |
+| VA  3     | 0x20  --> 0100000  | 00100000 --> 0x020  | NO    |
+| VA  4     | 0x3f   --> 0111111 | 00111111 --> 0x03f  | NO    |
+
+
+
+```
+ --------------- 0x00000000
+ |  Segment 0  |
+ |-------------| 0x00000014
+ |             |
+ |             |
+ |             |
+ |             |
+ |-------------| 0x000001ec
+ |  Segment 1  |
+ |-------------| 0x00000200
+```
+
+
+
+## Antworten
+
+1.  Die höchste erlaubte Adresse in Segment 0 ist 0x00000013. Die niedrigste valide Addresse des Segments 1 ist 0x000001ec. Die niedrigste illegale Adresse ist 0x0000014 und die höchste illegale Adresse ist 0x000001eb im gesamten Adressraum. Um zu testen ob das stimmt kann mann alle validen  virtuellen Adressen der Segmente UND jeweils (mindestens) eine über dem Limit mit `-A` angeben.
+
+     `-A 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,`
+
+     `106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127`
+
+
+2.   Der Aufruf muss wie folgt aussehen:
+
+    > ./segmentation.py -a 16 -p 128 -A 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 **--b0 0 --l0 2 --b1 16 --l1 2** -c
+
+    Die Flags `-l0` und `-l1` setzten jeweils das Limit für das Segment auf 2:
+
+    ​	Segment 0 nimmt also die virtuellen Adressen 0 und 1 an und
+
+    ​	Segment 1 nimmt die Adressen 14 und 15 an
+
+3.   Man sollte das Limit `-l` so wählen, dass es 90% der Adressen des Adressraums `-a` abdeckt. Dann werden die restlichen 10% der virtuellen Adressen über das gesetzte Limit gehen und einen Segmentation Fault auslösen.
+
+4.  Man setzt die Limits der Segmente mit `-l 0` auf 0, dann ist keine virtuelle Adresse valide. 
+
+5.  Im folgenden wird VA für virtuelle Adresse und PA für physikalische Adresse benutzt.
+
+    `Segment 0: 0x0000 bis 0x0040`
+
+    `Segment 1: 0x0380 bis 0x0400`
+
+    Höchste VA **0x16C** -> (mappt auf) höchste PA **0x400**
+
+    1024 - 364 = 660 (Segment 1 Offset)
+
+    | VA Nr. | VA HEX     | VA BIN          | Physical Address HEX   | PA DEC |
+    | ------ | ---------- | --------------- | ---------------------- | :----: |
+    | 0      | 0x0000005c | 00\|1011100     | Segmentation Violation |   -    |
+    | 1      | 0x00000011 | 00\|0010001     | **0x00000011**         |   17   |
+    | 2      | 0x00000043 | 00\|1000011     | Segmentation Violation |   -    |
+    | 3      | 0x00000021 | 00\|0100001     | **0x00000021**         |   33   |
+    | 4      | 0x0000006c | 00\|1101100     | Segmentation Violation |   -    |
+    | 5      | 0x0000007a | 00\|1111010     | Segmentation Violation |   -    |
+    | 6      | 0x00000050 | 00\|1010000     | Segmentation Violation |   -    |
+    | 7      | 0x00000037 | 00\|0110111     | **0x00000037**         |   55   |
+    | 8      | 0x000000ff | **01**\|1111111 | **0x00000393**         |  915   |
+    | 9      | 0x000000e9 | **01**\|1101001 | Segmentation Violation |   -    |
+    | 10     | 0x00000001 | 00\|0000001     | **0x00000001**         |   1    |
+    | 11     | 0x0000014c | **10**\|1001100 | **0x000003e0**         |  992   |
+    | 12     | 0x000000b4 | **01**\|0110100 | Segmentation Violation |   -    |
+    | 13     | 0x000000cf | **01**\|1001111 | Segmentation Violation |   -    |
+    | 14     | 0x0000012b | **10**\|0101011 | **0x000003bf**         |  959   |
+    | 15     | 0x00000084 | **01**\|0000100 | Segmentation Violation |   -    |
+
+    Zuerst überprüft man in welchem Segment die VA liegt, indem man auf das höchste bit der binären VA schaut. Wenn sie im Segment 0 liegt dann ist VA => PA und man kann prüfen, ob die Adresse im oben berechneten physikalischen Adressbereich von Segment 0 liegt. Wenn nicht => SEG FAULT.
+
+    Wenn die VA in Segment 1 liegt, dann muss man vorher den berechneten Offset vonn dezimal 660 oder hexadezimal 0x258 aufaddieren. Dann hat man die PA und kann dann schauen ob sie im physikalischen Adressbereich von Segment 1 liegt. Wenn nicht => SEG FAULT.

hw3/simu3/ANSWERS.md

@@ -0,0 +1,111 @@
+# Warmup
+
+Die Entwicklung des Speichers nach ausführen von `./malloc.py -n 10 -H 0 -p BEST -s` 
+
+```
+ --------------- 1000
+ |             |
+ |             |
+ |-------------| 1100
+```
+
+```
+ --------------- 1000
+ |   alloc'd   |
+ |-------------| 1003
+ |             |
+ |             |
+ |    FREE     |
+ |             |
+ |             |
+ |-------------| 1100
+```
+
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1003
+ |             |
+ |             |
+ |    FREE     |
+ |             |
+ |             |
+ |-------------| 1100
+```
+
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1003
+ |   alloc'd   |
+ |-------------| 1008
+ |             |
+ |    FREE     |
+ |             |
+ |-------------| 1100
+```
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1003
+ |    FREE     |
+ |-------------| 1008
+ |             |
+ |    FREE     |
+ |             |
+ |-------------| 1100
+```
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1003
+ |    FREE     |
+ |-------------| 1008
+ |   alloc'd   |
+ |-------------| 1016
+ |    FREE     |
+ |-------------| 1100
+```
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1002
+ |   alloc'd   |
+ |-------------| 1003
+ |    FREE     |
+ |-------------| 1008
+ |    FREE     |
+ |-------------| 1016
+ |    FREE     |
+ |-------------| 1100
+```
+```
+ --------------- 1000
+ |    FREE     |
+ |-------------| 1002
+ |   alloc'd   |
+ |-------------| 1003
+ |    FREE     |
+ |-------------| 1008
+ |   alloc'd   |
+ |-------------| 1015
+ |    FREE     |
+ |-------------| 1016
+ |    FREE     |
+ |-------------| 1100
+```
+
+Wie man sieht hat die Fragmentierung des Speichers bzw. der Free-Liste zugenommen.
+
+# Antworten
+
+1. Wenn zwei mal ein gleich großes Speicherstück alloziiert wird, dann wird nicht das wieder freigewordene Fragment genutzt, sondern ein neues reserviert. Auch Alloziierungen von kleineren Stücken bekommen keine Teile von wieder freigegebenem Platz. Also ensteht im allgemeinen eine höhere Fragmentierung als mit **BEST**.
+2. Die Struktur der Free-Liste ändert sich nicht, aber es werden weniger Elemente (Speicherblöcke) gesucht, bevor die Adresse zurückgeliefert wird. Je größer die Free-Liste, desto länger dauert es, diese zu durchsuchen. Das Flag **FIRST** verkürzt also die Suchzeit und somit auch die insgesamte alloc-Zeit.
+3. Die verschiedenen Sortiermechanismen:
+   - **ADDRSORT** sortiert die Liste mit dem freien Speicher nach der höhe der Adresse. Es verändert sich nichts zu vorher mit anderen Policies.
+   - Bei **SIZESORT+** sind die kleinsten *Stücke* vorne in der Liste. Bei **BEST** ist dann oft der Verschnitt, also 1-Byte-Blöcke am Anfang. 
+   - Bei **SIZESORT-** wird die Speicherliste absteigend nach der Größe der Blöcke sortiert. Diese Sortierung ist vorteilhaft für die Policy **FIRST**, da große Blöcke direkt am Anfang gefunden werden die sehr häufig für den angeforderten Speicher ausreichen. 
+4. Bei größeren Speicheranforderungen schlägt malloc fehl, mit dem Rückgabewert `-1` und die Free-Liste ist sehr groß. Wenn man nun die Verschmelzung von freiem Speicher mit `-C`  aktiviert, dann schlägt keine Allozierung mehr fehl und die Liste des freien Speichers ist kleiner. Die Sortierung der Liste spielt keine Rolle, da keine Fragmente über andere Adressen hinweg miteinander verschmolzen werden können.
+5. Wenn ein Faktor von über 50% erlaubt wird, dann bleibt die Liste klein, da der Speicher nicht wieder freigegeben wird. Bei Werten bis zu 100% kommt es definitiv zu einem Fehler bei der Alloziierung, da nicht genug freier Speicher vorhanden ist. Bei Werten, die gegen 0 gehen wird nach jedem **alloc** ein **free** aufgerufen und es ist immer wieder freier Speicher vorhanden.
+6. ​In dem man bei jedem **alloc** ein Byte mehr Speicher als davor anfordert, muss immer ein neuer "Block" angefangen werden. Dabei hilft die Policy BEST auch nichts mehr, da die neuen Allozierungen nie in die wieder frei gewordene kleinere Speicherstücke passt.
+

hw3/simu4/ANSWERS.md

@@ -0,0 +1,14 @@
+# Simulation 4 - Antworten
+
+1.1. Die Tabellengröße kann mit folgender Gleichung beschrieben werden: `T = a/P` mit `T` = Tabellengröße, `a` = Adressraumgröße und `P` = Seitengröße.
+
+1.2. Aus obiger Formel lässt sich schließen: Mit wachsendem Adressraum sollte die Tabellengröße mit gleichem Faktor wachsen, mit wachsender Seitengröße sollte die Tabellengröße mit gleichem Faktor sinken.
+
+1.3. Bei einem Kontextwechsel muss bei großer Seitengröße mehr geladen werden. Das benötigt Zeit.
+
+2. Je größer der Anteil der zum Adressraum zugeordneten Seiten wird, desto weniger Segmentation-Fehler treten auf.
+
+3. Der Parameter `-P 1m -a 256m -p 512m -v -s 3` ist unrealistisch, da eine Seitengröße von 1MB Größe viel zu groß ist, um praktikabel zu sein.
+
+4. Wenn der Adressraum größer als der physikalische Speicher ist, gibt das Programm eine Fehlermeldung aus.
+Weitere Fehler können manuell provoziert werden, wenn zum Beispiel eine negative Seitengröße (`math domain error`) oder die Seitengröße mit 0 angegeben werden (`float division by 0`). Auch beim angeben eines leeren Adressraums tritt ein Fehler auf (`must specify a non-zero address-space size`), genauso auch bei der physikalischen Speichergröße. Außerdem bekommt man einen Index-Fehler (`array index out of bounds`), wenn man eine sehr große (z.B. `2^31`) Seitengröße verwendet.