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.
Antworten
Martin Vieregg
Beiträge: 153
Registriert: Di 19. Aug 2014, 09:30

Wieviel RAM sieht OS/2 bei 4 GB?

Beitrag von Martin Vieregg » Di 15. Mai 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.)
Dateianhänge
mem.zip
(4.68 KiB) 18-mal heruntergeladen
aschn
Beiträge: 615
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn » Mi 16. Mai 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
Benutzeravatar
LotharS
Beiträge: 467
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS » Mi 16. Mai 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
Beiträge: 153
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg » Sa 19. Mai 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
Beiträge: 615
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn » Sa 19. Mai 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.
Zuletzt geändert von aschn am Sa 19. Mai 2018, 12:33, insgesamt 1-mal geändert.
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 826
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz » 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? TIA Frank
ehemaliger
Beiträge: 13
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger » Sa 19. Mai 2018, 14:55

Martin Vieregg hat geschrieben:
Sa 19. Mai 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 hat geschrieben:
Sa 19. Mai 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
Beiträge: 615
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn » So 20. Mai 2018, 01:24

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?

Code: Alles auswählen

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.
Zuletzt geändert von aschn am So 20. Mai 2018, 02:12, insgesamt 1-mal geändert.
Andreas Schnellbacher
erdmann
Beiträge: 164
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann » So 20. Mai 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.
Zuletzt geändert von erdmann am So 20. Mai 2018, 08:57, insgesamt 3-mal geändert.
Martin Vieregg
Beiträge: 153
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg » 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?
aschn
Beiträge: 615
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn » Di 22. Mai 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
Benutzeravatar
ak120
Beiträge: 824
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 » Mi 23. Mai 2018, 00:48

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.
Gast

Beitrag von Gast » Mi 23. Mai 2018, 10:47

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).
aschn
Beiträge: 615
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn » Mi 23. Mai 2018, 22:46

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