Page Faults

[Corelgott]

Hi @ all,

ich habe mal eine vll etwas doofe frage.
Ich habe in meiner App eine kleine eigene Komponetne, die 2 bilder per hand & viel scannline alpha-transparent verbindet / übereinanderlegt. Auf gut deutsch nen hover effekt macht.

Das poblem bei ist nun eigentlich, wenn man sich mit dem Task-Manager die App ansieht, erkennt man, dass die Page-Fault bei jedem hovern in die höhe schießen. Das Mem-Usage, also dir grösse des pogramms aber mehr oder minder gleichbleibend ist.

Nun meine frage. Ein Pagefault entsteht doch dann, wenn man auf einen speicherbereich zurgreift, den man vorher eigentlich nicht hatte, aber den das System als "ok" erachtete, in den man rein darf.

Ist dieses verhalten an sich ok? Oder besteht dort handlungs bedarf, damit das Programm sauberer bzw. stabiler läuft? kann man ein Programm Page-Fault-Frei machen? Oder ist dies ein mehr oder minder normales verhalten, was auch durchaus durch den Delphi mem-manager entstehen kann?

Was meint ihr daszu und wie würde man die "behebung" angehen?

thx im Voraus

Corelgott

[Luckie]

Ein Page Fault bezeichnet den Zugriff auf eine Speicherseite, die sich aktuell nicht im Arbeitsspeicher befindet und erst aus dem PageFile von der Festplatte nachgeladen werden muss.

Das ist ein vollkommen normales Verhalten des Speichermanagers von Windows und da gibt es nichts zu beheben.

[Corelgott]

thx Lucky,

wie immer formvollendet mit passendem detail-wissen...

nochmal thx & cya

Corelgott

[Bernhard Geyer]

Es gibt zwar die Möglichkeit bestimmte Speicherbereiche vom Paging auszunehmen aber dies sollte nur dem Betriebssystem vorbehalten sein um Kernel-Bereiche nicht auszulagen. Wenn jede x-Beliebige Anwendung dies in Mengen anfordern würde wäre das ganze Konzept der virtuellen Speicherverwaltung zur Einsparung von realen Speicher wieder ausgehebelt.

[Olli]

Zitat von Bernhard Geyer:

Es gibt zwar die Möglichkeit bestimmte Speicherbereiche vom Paging auszunehmen aber dies sollte nur dem Betriebssystem vorbehalten sein um Kernel-Bereiche nicht auszulagen. Wenn jede x-Beliebige Anwendung dies in Mengen anfordern würde wäre das ganze Konzept der virtuellen Speicherverwaltung zur Einsparung von realen Speicher wieder ausgehebelt.

Selbst Treiber sind ja beim sog. "NonPagedPool", wie der nicht-ausgelagerte (i.e. residente) Speicher bei uns genannt wird, beschraenkt. Hier gilt insbesondere, dass wer frueh kommt auch das groesste Stueck vom Kuchen ergattern kann. Deshalb gibt es auch manche Systemtreiber, welche sich auf einen Boottreiber (der Unterschied ist der Zeitpunkt zu dem ein solcher Treiber jeweils geladen wird) verlassen, der dann schonmal fruehzeitig einen dicken Brocken Speicher reserviert hat.

Uebrigens ist - vergleicht man es mit dem gesamten Adressbereich - der NonPagedPool auf x64 ein noch kleineres Stueck vorbehalten als auf x86. Geruechteweise sind es bei 32bit weniger als ein Achtel des gesamten Adressraums, wovon man aber bei einem einzigen Allokationsversuch nur rund 60MB ergattern kann.

Aber wenn man sich dann anschaut wie das alles arbeitet, sollte man sich darum keine Sorgen machen, dass der Speicher "langsam" wird. Der Pagewriter von NT ist ausgesprochen faul, weshalb nur dann was in die Auslagerungsdatei schreibt, wenn eine Seite wirklich urst lange (<- relativ!) nicht mehr benutzt wurde. PagedPool ist also ohnehin oft genug im physikalischen Speicher, kann aber ausgelagert werden.

Gluecklicherweise gibt es keinen Weg fuer Usermode-Programme NonPagedPool zu allozieren, es sei denn durch einen Treiber. Und solange der Treiberautor sich auskennt, wird er NonPagedPool moeglichst vermeiden. Der einzige Vorteil ist naemlich, dass NonPagedPool auf IRQLs (Interrupt Request Levels - nicht verwechseln mit IRQ oder ueberhaupt mit "Interrupts") hoeher als APC_LEVEL zugegriffen werden kann (kann schon, aber dann macht das System blau mit einem freundlichen Hinweis im Textmode). PagedPool wird so verwaltet, dass es technisch unmoeglich ist ab DPC_LEVEL drauf zuzugreifen, weil der Anfordernde u.U. warten muesste bis der Speichermanager die Seite in den physikalischen Speicher geholt hat. Dummerweise ist Warten aber eine Geschichte die ab DPC_LEVEL problematisch wird (einfach ein gutes Buch ueber Treiber finden, wenn's jemanden interessiert ) weshalb ab da PagedPool tabu ist. Gluecklicherweise laeuft eine jede Usermode-Anwendung auf PASSIVE_LEVEL (kleinster IRQL), so dass sie auf solche Geschichten keine Ruecksicht nehmen muss. Es gibt Ausnahmen in Sachen APC_LEVEL, aber das wird hier wohl zu detailliert

BTW: Was sucht dieser Thread in der Sparte Delphi-Language???

[Corelgott]

Hi,

ehh wow...

Also bei mir ging es eigentlich bloß um eine dumme kleine gui mit ein bischen bunt...
Aber sagen wir mal so, wenn ich das alles einigermaßen richtig verstehe, ist das ein komplett normales verhalten, woraus ich werder ableite, dass es handlungsbedarf gibt, noch das es etwas bringen würde. (Könnte ich denn handeln. Aber den Kernel-Treiber wollte ich nun nicht extra anfangen, nur damit mein button bunt ist )

Aber dennoch schon mal vielen dank, für die interessanten infos.

Zu dem Punkt, dass dieser Thread deplaziert ist: Hmm joar im nachhinein stimme ich da zu. Aber hinterher ist mal ja immer klüger und da ich vorher das problem ein bissel auf den Delphi-Mem-Mgr geschoben habe und es eigentlich 0 mit win-apis zu tun hatte...

Aber na ja, auch hier wurde mir ja geholfen ^^

thx & cya

Corelgott

[himitsu]

Zitat von Corelgott:

da ich vorher das problem ein bissel auf den Delphi-Mem-Mgr geschoben habe und es eigentlich 0 mit win-apis zu tun hatte...

der ist ja eh nicht gerade optimal ._.
(FastMM)

Und brauchst du auch nicht ... die WinAPIs verstecken sich bei dir alle in den "normalen" Delphifunktionen.