Ja nun die Zusammenfassung ein Rüsemeh zum Stoff von heute. Nun wir haben die Ladestrategie

zunächst im Detail behandelt, die bestimmt also wann ein Datum in den Hauptspeicher eingelagert

werden soll. Da haben wir gesehen, dass es Einzelanforderungstechniken gibt und

Vorausladetechniken halt gibt. Bei der Einzelanforderung geht man davon aus,

dass ein Zugriffsfehler halt existiert, also sowas wie ein PageFault. Und beim Letzteren

versucht man, wenn man an die Freiseitenpuffer denkt, eben praktisch diese Einzelanforderungslose

Zugriffsfehler zu vermeiden, indem man zum richtigen Zeitpunkt bereits die Seite eingelagert

halt hat. Die Ersetzungsstrategie bestimmt dann letztendlich nachher, welches Datum praktisch

seinen Platz im Hauptspeicher freimachen muss, um ein anderes Datum einlagern zu können. Das kann

also die Folge der Ersetzungsstrategie sein. Das kann übrigens auch die Folge der Ladestrategie

sein. Das kann natürlich auch die Folge der Platzierungsstrategie sein, um einen Prozess,

der gerade eine Speicheranforderung stellt, auf jeden Fall zügig weiter voranschreiten zu können.

Nun egal was die Ursachen halt dafür sind, wann die Strategie läuft, weil haben hier die globalen

und die lokalen Verfahren unterschieden. Hier bei den globalen Verfahren haben die alle gemeint,

dass die praktisch die Mengen aller residenten Seiten aller Prozesse im System eben unabhängig

von dem jeweiligen Versuch verursacht, eines Zugriffsfehlers halt analysieren, um herauszufinden,

wo ist ein Kandidat, welche Seite könnte ersetzt werden, ja, welchen Speicherplatz könnte man

frei machen. Da haben wir eben die klassischen, insbesondere LAU-Verfahren so kennengelernt und die

verschiedenen Varianten, die die Systeme so realisieren. Ein unerwünschter Effekt all

dieser globalen Verfahren ist das sogenannte Seitenplattan, dieses Threshing, ja, was also

Unternehmen deshalb einfach ist, dass dadurch eine enorme Systemlast generiert wird und einfach

die Prozesse auf der Anwendungsebene einfach nicht mehr oder nur noch sehr langsam vorankommen.

Denn gibt es lokale Verfahren, die sind mit dem Problem des Seitenplattans eben nicht konfrontiert.

Da werden dann halt, wenn es um die Ersetzung geht, halt eben nur die Menge der residenten Seiten des

Prozesses verwendet, der jetzt letztendlich den Zugriffsfehler verursacht hat und da haben wir

dann die beiden Techniken frei Seitenpuffer verwendet und dann die Arbeitsmenge, die Arbeitsmenge,

die man eben auch durchaus so als eine Art lokales LAU-Verfahren sehen kann. Nun der

Freiseitenpuffer ist sehr attraktiv, ist eigentlich eine ganz nette Technik, wo man wirklich die Anzahl

der PageFolds oder die Frequenz von PageFolds, wenn man es schlau macht, eben sehr, sehr wirklich

stark absenken kann, indem der Pager im Hintergrund agiert und immer versucht, eben genügend freie

Seiten, freie Seitenrahmen im Endeffekt im System zu halten muss, dabei aber zusehen, dass er nicht

zu häufig aktiv wird und er sollte auch zusehen, dass er nicht zu viele Seitenrahmen freilässt,

weil es ja bedeutet, dass möglicherweise der Grad an mehr Programmbetrieb denn dadurch gesenkt

wird. Nun bei der Arbeitsmenge versucht man so eine Sache ein bisschen dynamisch zu gehen,

aber da haben wir halt enorme Unkosten. Nicht nur die Unkosten, diese typischerweise aufgrund

der ganzen periodischen Abläufe, wie man es bei LAU gesehen hat, vorfindet, sondern wir brauchen

noch zusätzliche Leistungsanalysefunktionen in den Rechensystemen, um letztendlich nachher diese

Arbeitsmengen Fensterbreite zu bestimmen. Also zu wissen, wie weit in die Vergangenheit ausgehend

von einem bestimmten Beobachtungszeitpunkt möchte man denn zurückschauen, um praktisch die

Seitendeskriptoren zu analysieren. Ein wichtiger Punkt hier ist aber, dass die Arbeitsmenge eine

Menge von aktiven Seiten in der Residenzmenge eines Prozesses jeweils ist und manchmal genauso groß

ist wie die Residenzmenge oder eher dann halt kleiner ist. Diese residente Menge von Seiten,

die wir haben, der Residenzset, den sollte man doch nicht mit dem Workingset, mit der

Arbeitsmenge denn wirklich verwechseln. Die residente Menge der Residenzset ist statisch

und die Arbeitsmenge ist dynamisch. Das heißt also dieses R, was wir betrachtet haben, diese

Fensterbreite soll vom System eben dynamisch betrachtet werden und damit ist es eigentlich,

wenn man so will, die Arbeitsmenge eine dynamische residente Menge sozusagen, die ideale optimale

residente Menge eines Prozesses, nämlich von all den Seiten, die der Prozess dann wirklich in der

nächsten Zukunft benötigt. Und noch mal ein wichtiger Punkt, wenn es zu einer Seitenauslagerung

kommt und die Seite, und wir haben das Arbeitsmengenmodell, dann wird immer die gesamte