On Mon, Jun 26, 2000 at 06:16:58PM +0200, Stephan Goetter wrote:
Meiner Meinung nach sollte man bei fork() gleich den Platz im swap reservieren und geht so bestimmt 99% der Out-Of-Memory-Situationen in Linux aus dem Weg. Mit Optimierung hat das IMO nix zu tun.
Den Platz gleich im SWAP zu reservieren macht Solaris sicherlich auch nicht.
Wieso nicht. Reservieren heisst nur, von der Zahl eine freien Seiten etwas zu subtrahieren. Das kostest nix.
Die Frage ist, soll fork() so intelligent sein und rausfinden ob, im schlechtesteten Fall, genug Speicher frei ist oder nicht.
Ich finde das sollte er. Wie gross der aktuelle Prozess ist, ist wahrscheinlich leicht herauszufinden und dann die obige Differenz auszufuehren. Was ist so schrecklich daran, etwas mehr swap anzulegen wenn man mit groesseren Programmen hantieren will?
Das ist sicher 'ne Frage für einen Statistiker, Dr. Hamann oder ?
Statistik ist gut zum optimieren. Wenn
Oft macht man nach dem fork() nämlich ein exec(). Bei einem 200 MB Prozess ist das zwar ziemlich blöd programmiert, aber theoretisch unter Linux möglich, unter Solaris anscheinend nicht.
Beim exec werden die 200MB (in meinem Beispiel) wieder zum freien Speicher hinzugerechnet und gut ist. Ich bin mir fast sicher, dass andere Systeme das genauso machen. Apropos blöd programmiert; Angenommen du hast ein grosses CAD-Programm und willst drucken. Wie wuerdest du den lpr starten?
Der Sinn der Sache mit dem warten auf einen Schreibzugriff/Lesezugriff ist ja, daß das fork() dann wesentlich schneller ist, als wenn erst alles kopiert/reserviert wird.
Völlig richtig. Ich will doch auch nicht saemtliche Seiten sofort beim fork kopieren. Das macht kein Mensch mehr da das System damit fuer heutige Ansprueche unbenutzbar lahm wäre. Ich will nur die Zahl der Seiten, die im Schreibfall (worst case) von der Speicherverwaltung bereitzustellen sind, schon zum Zeitpunkt des forks von den freien Seiten wegrechen. Deshalb gab es auch die alte regel, den swap 2-3 mal so gross wie den Hauptspeicher zu machen. Dann hat man mit Prozessen bi zu einer fuer das System normalen Groesse (=Groesse des HS) keine Probleme. Groessere Brocken bekommmen eben ENOMEM beim fork und gut. Dieser Returnwert ist schon nicht ganz sinnlos.
Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100 verkaufe ich in der Hoffnung dass 20 Leute nicht anreisen. Kommen dann doch 85 muessen 5 mit anderen Hotels vertröstet werden. Auf Linux uebertragen wuerden 5 der 85 Gaeste erschossen. Dabei nimmt man nicht die zuletzt angereisten 5, sondern waehlt sich die Opfer zufaellig aus. Während billige Hotels das so machen, wird das in edlen Hütten nicht passieren. Diese lassen lieber mal eine Nacht 10 Betten frei als zu überbuchen. Wie so eine edles Hotel mit den betten sollte Linux mit dem Speicher umgehen. Die 10 freien Betten entspechen dort dann eine paar MB swap mehr auf der Platte.
Dahingehend ist dein fork()-Beispiel eher schlecht gewählt und unrealistisch.
Es ist *der* Hauptgrund, der zu den out_of_memory Situatioen fuehrt und diese bescheuerten kills beliebiger Prozesse nach sich zieht, die es fast nur in Linux gibt. Es gibt noch andere Varianten (Stack) um sich Speicher zu besorgen, der u.U. nicht wirklich da ist. Diese spielen aber nicht die grosse Rolle.
Reinhard