Wieviel RAM sieht OS/2 bei 4 GB?

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Martin Vieregg
Posts: 181
Joined: Tue 19. Aug 2014, 09:30

Wieviel RAM sieht OS/2 bei 4 GB?

Post by Martin Vieregg » Tue 15. May 2018, 23:55

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.)
You do not have the required permissions to view the files attached to this post.

aschn
Posts: 668
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 16. May 2018, 00:18

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.)
Andreas Schnellbacher

User avatar
LotharS
Posts: 483
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Wed 16. May 2018, 10:07

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.

Martin Vieregg
Posts: 181
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Sat 19. May 2018, 09:48

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.

aschn
Posts: 668
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Sat 19. May 2018, 12:32

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.
Last edited by aschn on Sat 19. May 2018, 12:33, edited 1 time in total.
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 859
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Sat 19. May 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? TIA Frank

ehemaliger
Posts: 19
Joined: Wed 22. Nov 2017, 23:46

Post by ehemaliger » Sat 19. May 2018, 14:55

Martin Vieregg wrote:
Sat 19. May 2018, 09:48
Also 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 wrote:
Sat 19. May 2018, 12:32
2,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.

aschn
Posts: 668
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Sun 20. May 2018, 01:24

Frank Wochatz wrote:
Sat 19. May 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?

Code: Select all

epm: F:\ > highmem -?

HighMem, a LX format 32bit DLL module 'loading above 512MB' marking utility,
Version 1.0.0
(C) 2012 Yuri Dario <yd@os2power.com>.
    Partially based on ABOVE512 (C) 2004 Takayuki 'January June' Suwa.

usage: HIGHMEM [-options] {DLL module file} ...
Without options, current DLL object information are dumped.
Options:
 --quiet   -q  quiets (no message)
 --verbose -v  verbose output (-v -v even more verbose)
 --code    -c  marks pure 32bit code objects as 'loading above 512MB'
 --data    -d  marks pure 32bit data objects as so
 --both    -b  marks both of pure 32bit code and data objects
 --unmark  -u  unmarks 'loading above 512MB' pure 32bit code/data objects
 --exclude -x file  list of files to be excluded (max 1024 entries
 --help    -?  show this help
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.
Last edited by aschn on Sun 20. May 2018, 02:12, edited 1 time in total.
Andreas Schnellbacher

erdmann
Posts: 197
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann » Sun 20. May 2018, 08:50

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.
Last edited by erdmann on Sun 20. May 2018, 08:57, edited 3 times in total.

Martin Vieregg
Posts: 181
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Tue 22. May 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?

aschn
Posts: 668
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Tue 22. May 2018, 22:11

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).
Andreas Schnellbacher

User avatar
ak120
Posts: 847
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Wed 23. May 2018, 00:48

Martin Vieregg wrote:
Tue 22. May 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.

Guest

Post by Guest » Wed 23. May 2018, 10:47

Martin Vieregg wrote:
Tue 22. May 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).

aschn
Posts: 668
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 23. May 2018, 22:46

Martin Vieregg wrote:
Tue 22. May 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.
Andreas Schnellbacher