[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian]: Swapspace foll - was dann




On Fri, 6 Nov 1998, Juergen Doser wrote:

> On Thu, Nov 05, 1998 at 08:39:46PM +0100, Michael Bramer wrote:
> > On Thu, Nov 05, 1998 at 10:37:31AM +0100, Juergen Doser wrote:
> > > On Wed, Nov 04, 1998 at 08:06:55PM +0100, Jens Ritter wrote:
> > > > martin@internet-treff.uni-koeln.de (Martin Bialasinski) writes:
> > > > 
> > > > > >> "AM" =3D=3D Andreas Mueller <andrmuel@rz.Uni-Osnabrueck.DE> writes:
> > > > > 
> > > > > AM> Was macht Linux eigendlich, wenn mal der Swapspace foll ist?
> > > > > 
> > > > > Nichts besonderes. Die Anwendungen, die Speicher verlangen bekommen
> > > > > sowas wie "out of memory" signalisiert.
> > > > 
> > > > ... und diese werden dann gestorben (äh, gekillt).
> > > > 
> > > 
> > > Nicht so schnell.
> > > 
> > > Meines Wissens läuft das ungefähr so ab:
> > > 
> > > 1. Anwendung frägt höflich das BS: 
> > >    "kannst du mir N Bytes zusatzlichen Speicherbereich geben?"
> > >    ( in C: malloc(N) )
> > > 
> > > 2. Im Normalfall sagt das BS:
> > >    "Natürlich, gerne. Hier ist er:" 
> > >    und reserviert dann diesen Speicher für diese Anwendung und 
> > >    'malloc(N)' liefert einen Zeiger auf diesen Speicherbereich
> > >    zurück.
> > >    In unserem Fall sagt das BS:
> > >    "Tut mir leid, soviel hab Ich nicht mehr",
> > >    es wird kein speicher reserviert und 'malloc(N)' liefert NULL
> > >    zurück.
> > > 
> > 
> > das ist nicht ganz richtig. 
> > 
> > Bei Linux bekommt man in der Regel immer einen gueltigen Zeiger zurueck. Auch
> > wenn der Speicher nicht da ist.
> > 
> > Daher kann es zu den Problem kommen, das init nicht sehr lange lebt...
> > 
> > 
> > Gruss
> > Grisu
> > -- 
> 
> Hi,
> 
> Ich dachte bisher immer, das ist nur bei 'fork()' der Fall. Dort ist es auch
> einigermaßen sinnvoll (Der Speicher wird ja im Moment noch gar nicht
> gebraucht).
> 
> Ich sehe allerdings keinen Sinn darin, daß 'malloc()' einen gültigen Zeiger
> zurückgeben soll, auch wenn kein Speicher mehr da ist. Auf was soll denn der
> Zeiger zeigen? Er kann auf keinen für diesen Prozess gültige Adresse zeigen
> (Es ist ja eben kein Speicher mehr da). Und wenn er auf eine ungültige Adresse
> zeigt, gibt es beim ersten Zugriff ein SIGSEGV, ohne daß der Prozess dies
> vermeiden könnte (indem er den Zeiger auf NULL prüft).
> 
> Über das Chaos, das entstünde wenn der Zeiger auf eine schon benutzte Adresse
> zeigt, will Ich mir erst gar keine Gedanken machen.
das ist meines Wissens nach bei allen Unix/Linux kernels unmoeglich, da 
jeder Prozess seinen eigenen virtuellen Adressraum hat, der beliebig 
ueber den physischen Speicher und die Swaps verteilt sein kann (oder noch 
nicht allokiert ist), das sieht dann etwa so aus

Speicher:                                 |Swap:
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|kernel   |
	  |prozess1   |         |proz.1 |     |proz1|
                      |prozess2 |       |2|pr2|     |prozess2 |
(vereinfacht: nur 2 Prozesse, erschwert: starke Fragmentierung)
der Kernel sieht den gesamten Adressraum so linear, wie er physisch
vorhanden ist und kann auf alle Prozesse zugreifen, die Prozess sehen ihren
ganz privaten Speicher so:
prozess 1: |code |daten      |....noch nicht angefordert....|stack|
prozess 2: |code   |daten      |...... .....................|stack|
der Kern mappt den Speicher dabei mit Einzelstuecken (Pages) von je
4kB, die in beliebiger Reihenfolge im Ram und auf den SwapSpaces
auftauchen koennen (je nach Bedarf)

fuer diejenigen, die sich jetzt fragen, wie der Kern gerufen wird:
der Prozess setz in die Prozessorregister einen Code fuer den gewuenschten
Kernelaufruf (Nummer des Aufrufs, siehe Kernel-header-files) und ruft 
Interrupt 80 auf, dabei wird das Protection level auf 0 getauscht und der
Kernelcode hat auf alles direkten Zugriff, wenn der Kern fertig ist wird 
der Interrupt und Level 0 verlassen (meistens ist es noch etwas 
komplizierter, da Aufrufe blockieren koennen oder der Scheduler mit einem 
"Du bist erst in 20ms wieder dran" dazwischenfunkt)

Vergleich Windows 95/98: Jeder Prozess sieht den Kernel und kann seine 
Funktionen direkt aufrufen, was dazu fuehrt, dass ein Prozess ausversehen 
in den Kernelspeicher schreibt und ein anderer (auf den er nicht direkt 
zugreifen konnte) eine halbe Stunde spaeter einen blauen Bildschirm 
ausloest.... wirklich spassig :-)

	viel Spass beim Kernelcode lesen,
	Konrad
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <your_email_address>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder:     630


Reply to: