[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


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

Re: [luga] mmap() Frage



On Tue, 2007-03-06 at 12:29 +0100, René Pfeiffer wrote:
> On Mar 06, 2007 at 1211 +0100, Bernd Petrovitsch appeared and said:
> > On Thu, 2007-03-01 at 00:25 +0100, René Pfeiffer wrote:
> > > [...]
> > > Ich habe jetzt noch etwas ausprobiert. In meinem Fall habe ich noch
> > > madvise() mit MADV_SEQUENTIAL dazugenommen, da ich das Logfile
> > > sequentiell lese. Bei einem 1,5 GB Logfile auf einem 384+128 MB System
> > > (RAM + Swap, Dual PII, ergo 32-Bit-System) stieg die Prozeßgröße stetig
> > 
> > Was für Kernel-Version läuft dort?
> 
> 2.6.20 oder neuer.

Da macht mbMn 128MB Swapspace bei 384MB RAM wenig Sinn. Der 2.6er
allokiert im Swapspace auch Pages, die im RAM sind - und gelegentlich
lagert er die auch "auf Verdacht" aus, weil ihm und der Disk grade fad
ist.

> > > an bis 100 MB ausgelagert waren. Ich habe dann dem mmap() Call noch
> > > MAP_NORESERVE als Option dazugegeben, um zu verhindern, daß die Mapped
> > > Pages im Swap Space landen. Jetzt ist der „gefühlte Speicherverbrauch”
> > > des Prozesses geringer.
> > 
> > Was tut die Applikation eigentlich?
> 
> Eigentlich liest sie nur eine Datei sequentiell.
> 
> > Wenn die eigentlich nur ein Logfile (eher mehr als weniger) sequentiell
> > liest, warum dann nicht einfach(er) read(2) und u.U. lseek(2) (bzw.
> > fgets(3) und u.U. ftell(3)/fseek(3)) verwenden?
> 
> Ja, das geht in jedem Fall. Ich dachte mir nur ich verwende mmap(), weil
> man dann bequemer auf die Daten zugreifen kann und im Userspace keine
> zusätzlichen Puffer braucht.

Der Preis dafür sind u.U. viele Buffer im Kernelspace.

> > Bei mmap(2) muß der Kernel entscheiden, wann er gemappte Pages
> > wiederverwendet. Da mögen obige Flags helfen, aber ich weiß nicht, wie
> > "aggressiv" die im Kernel beachtet werden.
> 
> Der Kernel nimmt das als Ratschlag an. Was er dann wirklich tut,
> entscheidet der VMM und die jeweilige Memory Situation. Ich habe die

So ist es.

> Erfahrung gemacht, daß bei mmap() Lesevorgängen auf sehr große Files
> immer alte Pages ausgelagert werden, weil RAM für Pages, die öfter
> gebraucht werden, wohl einfach schneller ist. Das dürfte von Read Ahead

Ja. Aber wenn du jede Page eh nur einmal liest, bringt das mbMn nicht so
arg viel.

> > Wenn die Applikation mit read(2) explizit etwas in diverse Buffer liest
> > (und die Buffer recycelt, sobald die Applikation sie nicht mehr
> > braucht), hat die Applikation die vollständige Kontrolle über den
> > verbrauchten Speicher, weil der Kernel nur die Pages verwenden wird, die
> > hinter den Buffern liegen.
> 
> Das ist mir klar, und das werde ich auch implementieren, wenn die
> Applikation sich zu arg aufführt. Bisher geht es mit MAP_NORESERVE und
> „swappiness” eigentlich ganz gut. Ich hatte nur angenommen man könne
> die Speichernutzung von mmap() besser steuern.

Und das ist worauf ich hinauswollte:
Eigentlich willst Du das ge-mmap-te gar nicht swappen (weil die
Applikation es eh nur einmal braucht). Das weißt Du (und jetzt ich und
die luga@ Liste und Google und ...), aber weiß das der Kernel drunter?

Wohl nicht a priori.

Deshalb will man/Du schlauerweise dem Hinweise geben. Gut.

Nur zum einem braucht Mechanismen dafür (madvise(2), /proc/sys/...,
etc.) und zum anderen müssen die in der VM natürlich auch
"berücksichtigt" werden.
*Wie* gut die berücksichtigt werden, müßte man 1mal untersuchen (und das
istmbMn eher mühsam und nach 2 Kernel-Releases ist es vielleicht wieder
anders).
Und bei "nur sequentielles Lesen" ist das Verwenden von mmap(2) mbMn
eher unüblich - und das könnte schon ein Grund sein, warum da
Kompromisse gemacht werden bzw. gar nicht wirklich ausgereizt wird.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010