OS2.org Forum

Mit dem kleinen Tool mem.exe kann man anzeigen lassen, wieviel Hauptspeicher OS/2 "sieht". Ich habe 8 GB installiert, also steht im 32-bit Raum 4 GB zur Verfügung. Angezeigt wird nur 2527 MB. Möglicherweise braucht die APU einen Teil des Speichers für Grafik. Welche Werte werden bei Euch angezeigt? (mem.exe siehe Attachment.)

Lies mal das hier und achte auf das, was Dmitry geschrieben hat.

Die Anleitung von Lewis:

At the boot blob, press Ctrl-C to get to the loader's command line, and type:

mem /a <Enter>

(Was der Loader nicht sieht, wird auch von OS/2 nicht gesehen.)

Vielleicht habe ich ja auch nur Glück, oder es liegt an meiner Virtualisierung (Win10 64 als Host, der Rest als Gäste in VBox). Mein ArcaOS bekommt von den spendierten 4GB laut 'mem /a' rund 3650 MB "available" durchgereicht.

Ich vermute nun, dass sich die interne Grafik meiner APU sich doch 1 GB von Speicher unterhalb von 4 GB unter den Nagel reißt. Die ArcaOS Ramdisk adressiert 4,5 GB an einem Stück. Also gibt es wohl keine 4 GB, sondern eine 3,5 GB Grenze bei OS/2. Ich denke ich kann damit leben, weil man mit OS/2 eh nur schwer so viel Speicher benötigt und ich die SWAPPER.DAT auf die 4,5 GB große Ramdisk gelegt habe.

2,5 GB RAM ist das Minimum. Damit kann man VAL auf max. 2 GB stellen. Sinnvoll wär ein Wert von 3 GB, damit man Mozilla und OOo parallel laufen lassen kann. Die DLLs beider Produkte sollte man natürlich mit highmem.exe hochladen.

Gibt es für das Hochladen von DLLs eine einfache Anleitung, die man auch versteht, wenn man sich die letzten 10 Jahre nicht mit der Thematik befaßt hat? TIA Frank

Martin Vieregg hat geschrieben: ↑Sa 19. Mai 2018, 09:48Also gibt es wohl keine 4 GB, sondern eine 3,5 GB Grenze bei OS/2.

Das ist keine OS/2 Problematik, sondern allgemeines Verhalten der Hardware. Unterhalb von 4G muß etwas Platz reserviert werden für eventuell vorhandene PCI(e) Einsteckkarten, ROM-Bereiche (z.B. ACPI-Tables) sowie CPU-eigene Ressourcen (z.B. APICs). Die 3,5 GB sind - unabhängig vom Betriebssystem - völlig normal.

aschn hat geschrieben: ↑Sa 19. Mai 2018, 12:322,5 GB RAM ist das Minimum. Damit kann man VAL auf max. 2 GB stellen.

Falsch. Das eine hat mit dem anderen nur bedingt etwas zu tun. Und zwar genau umgekehrt. Ein hoher Wert von VAL reduziert den virtuellen Adressbereich des Kernels (zugunsten der Applikationen). Nun ist es aber so, daß der Kernel zum Verwalten größerer Mengen physischen Speichers auch mehr virtuellen Adressraum benötigt. D.h. es kann Konstellationen geben, in denen ein VAL von 3 GB bei 2 GB physischem Speicher funktioniert, während dieselbe Einstellung bei 4 GB physischem Speicher nicht läuft.

Frank Wochatz hat geschrieben: ↑Sa 19. Mai 2018, 14:35 Gibt es für das Hochladen von DLLs eine einfache Anleitung, die man auch versteht, wenn man sich die letzten 10 Jahre nicht mit der Thematik befaßt hat?

Interessant sind die Optionen -c (Code) und -d (Daten). Dann natürlich noch -b (beides) und -u (rückgängig machen). Holger hat dazu etwas hier im Forum geschrieben. U.a. hat er auch empfohlen, welche System-DLLs sich eignen, dazu noch ob Daten oder Code.

Wenn die DLLs zu klein sind, lohnt es eher nicht. OOo hat ein Programmobjekt um alle DLLs hochzuladen (und bringt auch highmem.exe mit). Bei den Mozillen ist inzwischen auch jede DLL für beides geeignet. XUL.DLL bringt natürlich am meisten.

Ich würde mich definitiv auf das Hochladen von Code beschränken. Kein Mensch weiß welche DLLs auf Daten z.B. in ihrem Datensegment zugreifen müssen die (aus Gründen der "16-bit heritage") im niedrigen Speicherbereich liegen müssen.
Ich kann z.B. beisteuern, daß für die USBAUDIF.DLL die ich für USB audio support geschrieben habe auf keinen Fall die Datensegmente in den hohen Speicherbereich geladen werden dürfen, da die Daten von 16-bit Code aus zugreifbar sein müssen.
Das gleiche gilt übrigens auch für die Datei AUDIOIF.DLL sowie MMPM.DLL.

Wenn sich Firefox und OpenOffice DLLs beim oberen Speicherbereich (damit ist doch > 4GB gemeint?) bedienen, macht es dann Sinn, für die Ramdisk weniger als 4,5 GB zu reservieren? Wieviel weniger?

Martin, es geht nicht nur um Speicher, sondern darum, dass alle vier Speicherbereiche möglichst lange für das, was man machen will, ausreichen. Das sind Shared und Private Memory, beides bis 512 kB und darüber.

System Load von digi (Andrey Vasilkin) macht das gut anschaulich. Auch der VAL-Wert wird angezeigt. Als Modul wählst Du DosQuerySysInfo aus. Die Balken stehen für den noch verfügbaren Speicherbereich. Damit kann man häufig zusehen, wie ein Speicherbereich zur Neige geht, bevor das System oder die Anwendung trappt (mit oder ohne System-Trap).

Martin Vieregg hat geschrieben: ↑Di 22. Mai 2018, 21:55 Wenn sich Firefox und OpenOffice DLLs beim oberen Speicherbereich (damit ist doch > 4GB gemeint?) bedienen,

Das ursprünglich erwähnte Programm zeigt lediglich den von einigen OS/2-Kernelversionen gemeldeten physischen Speicher an. Gewöhnliche OS/2-Anwendungen oder auch Programme unter anderen vergleichbaren Betriebssystemen brauchen keinen physischen Speicher sondern virtuellen Speicher. Ein bestimmter Adreßbereich dieses virtuellen Speichers wird wohl gemeint sein, völlig unabhängig vom tatsächlich installierten physischen Speicher.

macht es dann Sinn, für die Ramdisk weniger als 4,5 GB zu reservieren? Wieviel weniger?

Vielleicht in Hollywood.

Martin Vieregg hat geschrieben: ↑Di 22. Mai 2018, 21:55 Wenn sich Firefox und OpenOffice DLLs beim oberen Speicherbereich (damit ist doch > 4GB gemeint?) bedienen, macht es dann Sinn, für die Ramdisk weniger als 4,5 GB zu reservieren? Wieviel weniger?

Soweit ich weiß benutzt die Ramdisk (also QSINIT bzw. das ArcaNoae Derivat davon) weder den niedrigen noch den hohen Private/Shared Speicherbereich sondern Speicher überhalb der physikalischen 4 GB Grenze der unter einem 32-bit Betriebssystem ohnehin nicht zugreifbar ist.
Also wie bekommt es also Ramdisk hin daß doch auf diesen Speicher zugegriffen werden kann ? Es aktiviert dazu "PAE" (physical address extension).
Über diesen Weg können physikalische Addressen >= 4 GB auf virtuelle Addressen ( = Addressen die der Prozessor zur Addressierung ausgibt) <= 4GB abgebildet werden.

Kurz und knapp: was du für die Ramdisk einstellt ist bezüglich oberem Speicherbereich völlig wurscht. Und deshalb kannst du immer die Ramdisk in ihrer maximalen Größe anlegen. Bei mir sind das bei 16 GB Speicher immerhin 13 GB (weil OS/2 wiederrum von seinem 4 GB virtuellem Addressraum nur 3 GB für Speicheraddressierung benutzen kann, das restliche 1 GB virtueller Addressraum geht für Dinge wie PCI address space und ähnliches drauf).

Martin Vieregg hat geschrieben: ↑Di 22. Mai 2018, 21:55 DLLs beim oberen Speicherbereich (damit ist doch > 4GB gemeint?)

Nein, geht doch nicht mit 32 Bit. Es geht bei OS/2 um den Bereich bis 512 MB und um den darüber (bis 4 GB), jeweils shared und private.