Arbeitsspeicherproblem von ArcaOS

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Arbeitsspeicherproblem von ArcaOS

Beitrag von Sigurd »

Da evtl. nicht alle Zugriff auf den ArcaOS Bugtracker haben, möchte ich hier gerne kurz da Ergebnis meiner Anfrage (Ticketnummer 2638) hinsichtlich des Arbeitsspeichers auf moderner Hardware (Laptops ab ca. 2014) mitteilen:

Ich hatte beobachtet, dass ArcaOS immer weniger Arbeitsspeicher als verfügbar anzeigt (auf dem X250 2.4 GB, auf dem T25(=T470) gar nur noch 1.5 GB) statt der theoretisch möglichen 4 GB (oder 3.5 GB, sofern die interne Grafikkarte da etwas abknappst). Jedenfalls hat sich der dafür zuständige Experte dies Problem angesehen und meinte, dass daran nichts zu ändern sei. Die Hardware wäre nicht defekt und das Ergebnis ist das, was ArcaOS liefern könnte. Aus OS/2 Sicht ließe sich das nicht ändern, nur durch BIOS Änderungen, was natürlich völlig unrealistisch ist.

Tatsächlich laufen sowohl das X250 als auch das T25 trotzdem sehr schnell und flüssig mit OS/2 bzw. ArcaOS. Auch mit diesem "geringeren RAM". Es besteht ja schon seit Jahren das Problem mit dem Lower/Shared RAM, dass dieser schnell voll ist (Open Office, Firefox usw.). Wie bzw. wann oder womit würde man in der Praxis denn die restlichen Speicherbereiche bis 4 GB überhaupt auslasten können? Mit Virtualbox,könnte ich mir vorstellen,nur das gibt es ja auch nicht in vernünftiger Form. Für Hinweise dazu wäre ich dankbar.

Trotzdem bleibt natürlich auch das Problem, obwohl OS/2 ja nun wirklich lange durchgehalten hat, das man nun endgültig für neuere Hardware den Stecker ziehen muss. Neben USB3, Sound und WLAN bleibt nun auch der RAM auf der Strecke. Und so kann man das System natürlich auch nicht mal im Ansatz jemandem vorstellen, wenn es heißt: aber Achtung! 1,5 GB RAM sind Max! Was meint Ihr?
Zuletzt geändert von Sigurd am Do 19. Sep 2019, 08:49, insgesamt 1-mal geändert.
OS/2 versus Hardware - Maximum Warp!
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

In deiner Einschätzung gebe ich dir Recht: OS/2 ist für moderne HW tot.

Trotzdem ein paar Korrekturen:

Kurzinfo:
linear: Addresse die ein Programm zum Zugriff angibt
physikalisch: Addresse die nach den diversen Addresstransformationen die die CPU durchführt tatsächlich auf den Addressbus gelegt wird

Generell hat OS/2 das Problem dass der GESAMTE LINEARE Addressbereich immer auf 4 GByte beschränkt bleiben wird. Außerdem wird was den Kernel und "herkömmliche" Treiber/IFS/Systemkomponenten angeht auch der GESAMTE PHYSIKALISCHE Addressbereich auf 4 GByte beschränkt bleiben. Das liegt in beiden Fällen daran, dass nur 32-bit Worte in den Kernelverwaltungsstrukturen für die Darstellung von linearen als auch physischen Addressen vorgesehen sind.
Dann kommt hinzu, dass der gesamte lineare Addressbereich in einen Teil aufgespaltet werden muss der für Applikationen nutzbar ist (wenn alles gut geht und VIRTUALADDRESSLIMIT entsprechend hoch gesetzt ist, ist dieser Bereich 3 GB groß) und einen Systembereich, der unter anderem für die Addressierung von PCI devices sowie für die Grafikapertur sowie für alle Kernelmanagement Datenstrukturen gebraucht wird, denn dieser Systembereich muss IMMER und zu jeder Zeit zugreifbar sein, egal welche Applikation gerade auf einer CPU/core ausgeführt wird (wenn der Applikationsbereich 3 GB groß ist, ist der Systembereich also 1 GB groß). Der Applikationsbereich wiederrum teilt sich dann in "low" und "high" memory auf und die Probleme und Krücken die sich daraus ergeben haben wir alle schon erlebt ("high" memory kann von 16-bit Code aus bestimmten Gründen [compatibility mapping] nicht benutzt werden, und dummerweise gibt es noch hier und da 16-bit Applikationscode in OS/2 auch wenn das nicht sofort offensichtlich ist).

Dummerweise blendet moderne HW manchmal Teile des physikalischen Speichers über die 4 GByte physikalische Addressgrenze ein obwohl unterhalb dieser Grenze noch größere Addressbereiche frei wären (und das passiert mit Sigurds HW). Dies ist ein Problem was sich offensichtlich generell nicht beheben läßt ohne das Chipset komplett umzuprogrammieren und das wiederrum kann natürlich nicht generisch sein (wäre für jeden Chipsatz spezifisch durchzuführen).

Was aber geht ist, dass sich physikalischer Speicher der über der 4 GByte physikalischen Addressgrenze liegt, mittels PAE auf lineare Addressen abbilden läßt die unterhalb der 4-GByte linearen Addressgrenze liegen. Allerdings gibt es keine GENERISCHE Art um PAE von Applikationen und Treibern zu nutzen und der Kernel und die "herkömmlichen" Treiber wissen natürlich gar nichts davon.
Die RAM-Disk die mit QSINIT mitkommt ist dazu in der Lage (der QSINIT Author ist auch der, der die RAM-DISK programmiert hat), allerdings nehme ich an, dass diese immer nur TEILE des Arbeitsspeichers über der 4 GByte physikalischen Addressgrenze in den linearen Addressbereich einblenden kann weil der lineare Addressbereich IMMER NOCH auf 4 GByte beschränkt bleibt. Wahrscheinlich gibt es deshalb ein "Speicherfenster" im oben genannten Systembereich in den dann ein Teil des Speichers über 4 GByte eingeblendet wird. Meine RAM-DISK hat z.B. eine Größe von 13 GB (bei 16 GB physikalischer Speichergröße), die können natürlich nie in ihrer Gänze zu einem Zeitpunkt in den linearen Addressraum eingeblendet werden.
Das Feature aber ist natürlich schön (eine schnelle RAM-DISK) aber es behebt nicht das eigentliche Problem.
Zuletzt geändert von erdmann am Do 19. Sep 2019, 10:26, insgesamt 3-mal geändert.
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

Sehr gut Lars, vielen herzlichen Dank!
OS/2 versus Hardware - Maximum Warp!
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Gibt es denn Erfahrungen bzgl RAM mit dieser Hardware in einer Virtuellen Maschine?
Auf meiner VBox-VM unter Win10 auf "uralter" PC-Hardware aus 2011 sowie T430 (2013) sehe ich das Problem nicht, aber soll ja nix heißen. (PAE ist gesetzt). Das scheint mir die einzige Überlebensbox...

@Sigurd: darf ich da noch UEFI/GPT anfügen? :)
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Ich denke man sollte nach anfügen, dass wenn einem OS der Speicher ausgeht, dass dieses dann Teile des Speichers ins Swapfile auslagert. Das heißt, es können schon noch mehr Anwendungen gestartet werden und man kann weiterarbeiten, auch wenn physisch der Speicher aus ist. Nur dann wird eben ausgelagert (swap). Das kostet Zeit und bremst das System. Beim swappen auf mechanische Platten war das natürlich ziemlich langsam und nervig. Wenn allerdings auf eine RAM-Disk ausgelagert wird, ist das möglicherweise gar nicht mal so stark spürbar.

Sigurd, hast du den Hinweis versucht auf eine RAM-Disk zu swappen um zu sehen, ob man damit brauchbar leben kann?

Lars, bitte korrigiere mich wenn ich da jetzt Blödsinn geschrieben habe. Ich bin da nicht so der Experte und reime mir manchmal auch was zusammen.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

1) @ Lothar: das Problem ist nicht zu alte HW. Ganz im Gegenteil, das Problem ist zu neue HW, nämlich solche, die eigentlich nur noch erwartet mit einem 64-bit Betriebssystem betrieben zu werden. Es wäre also gut wenn VBox dem OS/2 vorgaukeln würde dass es auf uralter HW läuft. Allerdings benutzt VBox für die Speicheraddressierung auch für den Guest quasi das gleiche physikalische Memory Layout wie für den Host (und kann auch nicht anders soweit ich weiß). Insofern kann da nichts vorgegaukelt werden.

2) @ Andi: Was du schreibst ist richtig, ich hatte in der Tat vergessen zu erwähnen dass die Swapfile natürlich erlaubt dass alle gleichzeitig laufenden Applikationen ZUSAMMENGENOMMEN viel mehr als nur 4 GB Speicher addressieren können (man bedenke dass ja JEDE Applikation bis zu 3 GB linearen Speicherraum nutzen kann). Und demzufolge war in dem von Sigurd rezitierten AN Problemreport auch der Vorschlag die Swapfile eben auf die RAM disk zu legen um das Problem "abzumildern". Allerdings ist das natürlich bestenfalls ein Hack aber keine wirklich gute Lösung. Denn Swappen bedeutet, dass dauernd Exceptions erzeugt werden (wenn eben Speicherseiten nicht im Hauptspeicher sind sondern in die Swapfile ausgelagert wurden) um dann die ausgelagerten Speicherseiten wieder in den Speicher zu laden (und andere von anderen Programmen die gerade nicht laufen auszulagern). Das ist nicht gerade effizient. Klar ist es dann noch besser wenn von einer RAM Disk wieder in den Speicher geladen wird anstatt von einer echten Harddisk.
Man sollte sich aber klarmachen dass da eben ein RAM disk Treiber (HDDISK.ADD oder wie er heißt) bemüht werden muss der dann erst umständlich einen bzw. mehrere Sektoren addressieren und die Daten einlesen muss (bedenke: ein "Swapfile" ist eben genau das: eine Datei). Und wie bei allen anderen OS/2 Treibern auch ist HDDISK.ADD ein 16-bittiger Treiber (zumindestens größerenteils). Und das wiederrum ist eine Performancekatastrophe.
Zuletzt geändert von erdmann am Do 19. Sep 2019, 14:55, insgesamt 2-mal geändert.
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Und wie verhält es sich mit dem OS/4-Kernel? Hat jemand schon Erfahrungen gesammelt damit?
Bzw. was ist, wenn Arca Noea es tatsächlich schaft, die bisherigen Bemügungen, OS/2 auf einem UEFI-System booten zu können, zur Marktreife zu bringen? Würde nicht auch das evtl. einige Probleme lösen?
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

1) Was Speicher angeht unterliegt OS/4 den gleichen Restriktionen wie OS/2. Es ist halt ein 32-bit Betriebssystem und kein 64-bit Betriebssystem

2) UEFI ist ein anderes zu lösendes Problem, zusätzlich zum diskutierten Speicherproblem. Da bestehen wohl noch Chancen dass es auch für OS/2 lösbar ist.

3) Und auch wenn das UEFI Problem gelöst ist, besteht dann noch das GPT Problem. Und obwohl UEFI und GPT nichts miteinander zu tun haben, erzwingt z.B. Windows die Nutzung von GPT wenn der Rechner im "UEFI Mode" (also bei aktivem UEFI Bios und deaktiviertem legacy BIOS) installiert wird. Da alle neuen Rechner nur noch UEFI haben werden, werden also vorinstallierte Windowssystem das GPT Partitionslayout haben. Und damit kann OS/2 nicht umgehen und ich rechne auch nicht damit das sich das ändert weil das Änderungen im Kernel und auch in den Device Managern (OS2DASD.DMD) nach sich ziehen würde. Und in diversen Programmierschnittstellen und weiteren Systemkomponenten. Wenn man dann noch OS/2 betreiben will wird man es wohl oder übel auf einer separaten Platte installieren müssen mit dem konventionellen MBR Partitionslayout.
Zuletzt geändert von erdmann am Do 19. Sep 2019, 19:57, insgesamt 2-mal geändert.
Benutzeravatar
MikeK
Beiträge: 369
Registriert: Mo 23. Dez 2013, 13:51
Wohnort: Potsdam

Beitrag von MikeK »

Hi Sigurd,
auf meinem X250 mit 8 GB RAM sieht es beim Speicher wie folgt aus:
eCS mit QS_Loader zeigt ca. 2,9 GB an
eCS21.DE
eCS21.DE
Die AOS (5.0.3 und 5.0.4) Testinstallationen zeigen auch ca. 2,9GB an. Der QS_Loader wird hier nicht benötigt.
AOS5.0.4
AOS5.0.4
Ich habe dabei immer eine RAM-Disk angelegt und dort die Swapper.dat platziert.
Grüße aus Taipeh,
Mike
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

Hi Mike,

Und: Hi Alle, vielen Dank für Eure Gedanken und Beiträge!!!

Deine Infos haben mich auf eine weitere Idee gebracht. Vielleicht zeigt ja das Tool "OS/2 Kernel" aus der Vollversion von Xworkplace schlicht auch nur eine falsche Größe bei mir an?

Ich habe gerade mal das Thinkpad25 mit meiner eigenen OS/2 Ausgabe zur Hand und etwas probiert. Folgende Ergebnisse kamen da raus:

1.) Wenn man im BIOS den Speicher für die Grafikkarte von 256 auf 512MB (oder umgekehrt) ändert, verändert sich die Anzeige des verfügbaren Speichers in "OS/2 Kernel", von 1.200 auf 1.400 und zurück. Da das TP 25 noch zusätzlich eine interne Nvidia Grafikkarte mit 2GB Speicher hat, sehe ich meine Vermutung schon etwas mehr bestätigt, dass diese zusätzlichen 2GB von "OS/2 Kernel" nicht erkannt oder ausgelesen werden können. Diese Vermutung habe ich ja schon lange, dass die internen Grafikkarten wohl Einfluß auf diese Anzeige nehmen.

2.) Jedenfalls habe ich mal ein anderes Programm (heisst: SYSTEM LOAD)gestartet, welches beim auslesen des verfügbaren Speichers dann andere Angaben liefert. Hier bei Interner Grafik auf 256MB (statt 512 MB), die Anzeige von OS/2 Kernel direkt daneben.
Einmal habe ich das mit dem ArcaOS SMP201 Kernel und einmal mit dem OS4 Kernel gemacht. Die Ergebnisse sind FAST dieselben.
T25Speicher-IBM.png
TP25Speicher-OS4.png
Im unteren Speicherbereich werden beim OS/4 Kernel andere Werte angezeigt, als mit dem ArcaOS Kernel.

IBM: 262/263 MB
OS4: 272/247 MB

Ob das überhaupt irgendwas aussagt oder einen Unterschied macht? Das Problem interessiert mich jedenfalls. :-)

Vielleicht sehe ich ja ein Problem, das es gar nicht gibt, weil ich dem falschen Programm Glauben geschenkt habe?

Welches Programm erscheint Euch sehr zuverlässig zwecks Anzeige des "richtigen" Arbeitsspeichers, welches sollte ich einmal einsetzen?
Zuletzt geändert von Sigurd am So 22. Sep 2019, 22:37, insgesamt 2-mal geändert.
OS/2 versus Hardware - Maximum Warp!
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Offensichtlich hast Du immer noch nicht den Unterschied zwischen virtuellem und physischem Speicher verstanden. Das linke Fenster zeigt virtuellen Speicher an. Das hat nichts (NICHTS, NICHTS und nochmals: absolut NICHTS) mit dem im System installierten bzw. vom System erkannten physischen Speicher zu tun! Wie Lars schone versuchte anzudeuten: wenn ein Hardwareentwickler ein Gerät so konzipiert, daß z.B. von insgesamt 4GB vorhandenem RAM die unteren 2GB von 0 aus losgehen und bei 2GB enden, die oberen aber im Bereich von 4GB bis 6GB angesiedelt sind, dann wird der betagte OS/2-Kernel die oberen 2GB nicht sehen. Weil er nämlich 32bittig ist und noch nie etwas von PAE gehört hat. Allenfalls der RAM-Disk-Treiber des erwähnten OS/4 kann diesen Bereich (unter Umgehungen des Kernel-Speichermanagements) nutzen.
Zuletzt geändert von ehemaliger am So 22. Sep 2019, 23:15, insgesamt 2-mal geändert.
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Diese Probleme bringen natürlich auch 32-Bit Windows-Systeme mit sich und sind nicht reiner OS/2-Natur. Wie ja bereits mehrfach angemerkt wurde.

Es wäre mal interessant zu veruchen, falls möglich, den Arbeitsspeicher "abzurüsten". Einigen Berichten zufolge wurde von einigen Windows-Versionen anschließend mehr Speicher erkannt.
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

ehemaliger hat geschrieben: So 22. Sep 2019, 23:13 Offensichtlich hast Du immer noch nicht den Unterschied zwischen virtuellem und physischem Speicher verstanden.
Ja, das könnte zu der Schlussfolgerung führen, dass ich deshalb noch einmal nachfrage. Wenn ich es in diesem Zusammenhang (s.u.) verstehen würde, wäre das ja vermutlich nicht notwendig, oder? Fragen werden doch im allgemeinen gestellt, wenn etwas unklar ist, oder habe ich da was übersehen?
ehemaliger hat geschrieben: So 22. Sep 2019, 23:13 Das linke Fenster zeigt virtuellen Speicher an.
Und dies hätte ich genau woran erkennen können? Als Laie in diesen Dingen (s.o.) erschließt sich mir das (leider) nicht auf den ersten Blick. Einen Hinweis auf "Virtuellen Speicher" kann ich zumindest diesem Programmfenster nicht unmittelbar entnehmen.
ehemaliger hat geschrieben: So 22. Sep 2019, 23:13Wie Lars schone versuchte anzudeuten: wenn ein Hardwareentwickler ein Gerät so konzipiert, daß z.B. von insgesamt 4GB vorhandenem RAM die unteren 2GB von 0 aus losgehen und bei 2GB enden, die oberen aber im Bereich von 4GB bis 6GB angesiedelt sind, dann wird der betagte OS/2-Kernel die oberen 2GB nicht sehen. Weil er nämlich 32bittig ist und noch nie etwas von PAE gehört hat. Allenfalls der RAM-Disk-Treiber des erwähnten OS/4 kann diesen Bereich (unter Umgehungen des Kernel-Speichermanagements) nutzen.
Das hatte ich (man glaubt es kaum) schon lange verstanden, nutze ich doch schon die RAM Disk seit Jahren, war glaube ich einer der ersten, die QSINIT überhaupt mit eingebaut hatten, lange bevor ArcaOS das getan hat. Anhand des Programms im Scrennshot Links kann ich (s.o.) aber keinen Hinweis erkennen, dass es sich um virtuellen Speicher handelt, der hier angezeigt wird. (Sorry für die Wiederholung).
ehemaliger hat geschrieben: So 22. Sep 2019, 23:13Das hat nichts (NICHTS, NICHTS und nochmals: absolut NICHTS) mit dem im System installierten bzw. vom System erkannten physischen Speicher zu tun!
Wie, das hat NICHTS damit zu tun? Habe ich das nach der dreifachen Wiederholung verstanden? Ist die Frage damit beantwortet?
OS/2 versus Hardware - Maximum Warp!
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

Hallo Sigurd,

hast Du schon mal THESEUS4 verwendet um Informationen über den eingebauten und von OS/2 erkannten RAM zu bekommen?
THESEUS_GSI.jpg
Die Anzeige wurde auf meinem X250 unter ARCAOS 5.0.3 erstellt.

Zu der vorangegangenen Diskussion nur soviel:
Man darf den erkannten physisch vorhandenen RAM nicht mit vom System bereitgestellten virtuellen Adressräumen verwechseln.
Zuletzt geändert von wilfried am Mo 23. Sep 2019, 10:18, insgesamt 1-mal geändert.
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

MikeK hat geschrieben: Fr 20. Sep 2019, 06:59 Hi Sigurd,
auf meinem X250 mit 8 GB RAM sieht es beim Speicher wie folgt aus:
eCS mit QS_Loader zeigt ca. 2,9 GB an
ECS21D00.jpg
Die AOS (5.0.3 und 5.0.4) Testinstallationen zeigen auch ca. 2,9GB an. Der QS_Loader wird hier nicht benötigt.
AOS50400.jpg
Ich habe dabei immer eine RAM-Disk angelegt und dort die Swapper.dat platziert.
Grüße aus Taipeh,
Mike
Hallo Mike + Alle:

ich habe mal am X250 den internen Grafikspeicher im BIOS von 512 auf 256MB runtergestellt, und schon zeigt mir der Speicherwert entsprechend mehr an.
X250-256MBGraphicRAM.jpg
Insofern dürfte sich das wohl erledigt haben. Beim Thinkpad 25 ist dann noch die interne NVidia mit 2GB anzurechnen.

Vielen Dank.
OS/2 versus Hardware - Maximum Warp!
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Apropos letzter Screenshot: ich bin mir nicht sicher weil ich ArcaOS nicht benutze, aber mit "low" und "high" memory sind glaube ich Speicher unterhalb der physikalischen 4 GB Grenze ("low") und Speicher über der physikalischen 4 GB Grenze ("high") gemeint. also NICHT dass was unter OS/2 als "low" und "high" (virtual) memory bezeichnet wird. Ja, es ist verwirrend ...
Gerhard
Beiträge: 160
Registriert: So 20. Jul 2014, 00:04
Wohnort: Wuppertal

Beitrag von Gerhard »

Hm, also es wäre sehr gut, wenn jemand beim nächsten Treffen mal über die diversen Speicherbereiche und die oben genannten Möglichkeiten zur Speichererweiterung etwas sagen/berichten könnte.
(das war zwar beim letzten Treffen mal so nebenbei ein Thema, aber leider nur nebenbei)

So ein wenig Theorie und vor allem Praxis. Oder bin ich der einzige hier der ein Defizit hat?

Viele Grüße,
Gerhard
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Gerhard hat geschrieben: Mo 23. Sep 2019, 16:03 Hm, also es wäre sehr gut, wenn jemand beim nächsten Treffen mal über die diversen Speicherbereiche und die oben genannten Möglichkeiten zur Speichererweiterung etwas sagen/berichten könnte.
So wild ist das doch gar nicht. Ich will sehen, dass ich in den nächsten Tagen etwas zusammen geschrieben kriege. Damit sollte man dann auch die vielen nützlichen Beiträge von Holger hier verstehen, z.B. auch diese.
Andreas Schnellbacher
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Sigurd hat geschrieben: Mo 23. Sep 2019, 09:11Und dies hätte ich genau woran erkennen können? Als Laie in diesen Dingen (s.o.) erschließt sich mir das (leider) nicht auf den ersten Blick. Einen Hinweis auf "Virtuellen Speicher" kann ich zumindest diesem Programmfenster nicht unmittelbar entnehmen.
Da von "private" und "shared" Arenen die Rede ist, muß es sich um virtuellen Speicher handeln.
Sigurd hat geschrieben: Mo 23. Sep 2019, 09:11Wie, das hat NICHTS damit zu tun? Habe ich das nach der dreifachen Wiederholung verstanden? Ist die Frage damit beantwortet?
Kurzer Crashkurs in OS/2 Memory-Management: Jeder Prozeß sieht einen virtuellen Adressraum von 4GB. Der unterteilt sich im wesentlichen in 5 Bereiche (Arenen). Ab Adresse 0 beginnt der (low) private Bereich, der bei weiteren Speicheranforderungen nach oben hin wächst. Und zwar so lange, bis er mit dem (low) shared Bereich kollidiert. Low shared beginnt bei 512MB und wächst nach unten hin. Also auf low private zu. Der gesamte Low-Bereich hat die Eigenschaft, daß er auch für 16bit-Programme erreichbar ist. Ab 512MB aufsteigend erstreckt sich der high private Bereich. Auch dieser wächst nach oben hin bis er mit high shared kollidiert. Letzterer beginnt bei VIRTUALADDRESSLIMIT und wächst - wie auch low shared - nach unten. Der Bereich von VIRTUALADDRESSLIMIT bis zum Ende (4GB) ist die System-Arena. Dort befinden sich der Kernel, Gerätetreiber, Filesystemcaches sowie memory-mapped Devices. Wenn der Kernel zwischen verschiedenen Prozessen umschaltet, dann werden im Prinzip nur die Private-Bereiche ausgetauscht, während shared und system erhalten bleiben. Das hat einen unschönen Nebeneffekt: Der maximal systemweit verfügbare shared-Bereich wird durch den Prozeß mit dem größten Verbrauch an private - Speicher bestimmt. D.h. wenn eine Prozeß A 200MB low private anfordert, dann bleiben noch 312MB Platz für low shared. Läuft aber im System eine Prozeß B, welcher 400MB low privat anfordert, dann reduziert er den low shared Bereich für alle anderen Prozesse (also auch für Prozeß A) auf 112MB. Wenn Prozeß A nun weitere 200MB low shared benötigt, dann haben wir ein Problem! Die QSV_MAXxxxMEM-Werte zeigen im Übrigen einen Schnappschuß der zum aktuellem Zeitpunkt vorliegenden virtuellen Speicherbelegung dar.
Das alles spielt sich im virtuellen Umfeld ab. D.h. es hat nichts mit physisch vorhandenem Speicher zu tun. Die Übersetzung virtueller Adressen in physische wird über Pagetables realisiert. Angenommen, ein Program möchte eine Sprungbefehl auf Adresse 1000 ausführen. Das ist natürlich eine virtuelle Adresse. Wenn jetzt z.B. das Betriebssystem unser Programm auf die physische Adresse 10000 geladen hat, dann sorgte es - durch entsprechende Initialisierung der Pagetables - dafür, daß in Wirklichkeit zur physischen Adresse 11000 gesprungen wird. Das System kann jede physische Adresse (in 4K Blöcken) auf jede virtuelle Adresse "umverdrahten". Wenn nicht genügend physischer Speicher zur Verfügung steht, dann beginnt das System zu "pagen". D.h. es könnte in unserem Beispiel bei Speicherknappheit den Block von 10000-14000 ins Pagefile auslagern und anderweitig verwenden. Wenn wir nun unseren Sprung ausführen, dann stellt das System fest, daß der Zielblock gar nicht vorhanden ist. Das nennt man einen Pagefault. Der wird intern dadurch behandelt, daß ein Stück freier Speicher gesucht, die entsprechenden Daten aus dem Pagefile dort hin geladen und der abgebrochene Sprungbefehl wiederholt wird. Dabei kann die neue physische Adresse z.B. 20000 sein, was bedeutet, daß unser wiederholter Sprung nun auf die physische Adresse 21000 geht.

Wie Du sieht gibt es keinen direkten Zusammenhang zwischen physischen und virtuellen Adressen. Der virtuelle Adressraum ist immer 4GB groß. Auch wenn er nur zu einem kleinen Teil mit physischem Speicher bzw. Pagefiledaten hinterlegt ("committed") ist. Da der Kernel selbst aber kein PAE unterstützt, sind für ihn physische Adressen oberhalb von 4GB unerreichbar. Hätte man den Kernel rechtzeitig weiterentwickelt, wäre dieses Problem eventuell vermeidbar gewesen. Das hätte aber auch Eingriffe in die Gerätetreiber-Schnittstelle und damit evtl. Inkompatibilität zu bestehenden Treibern bedeutet.
Benutzeravatar
Rolf
Beiträge: 71
Registriert: Mi 15. Jan 2014, 21:58
Wohnort: Rapperswil / Jona (Switzerland)

Beitrag von Rolf »

Danke für Deine Erläuterungen

Jetzt beginne auch ich (vielleicht) langsam das Ganze zu verstehen. Ich hab ja in BS_Info einfach die QSV_MAXxxxMEM-Werte ausgegeben ohne detaillierte Kenntnisse. Das sind ja entsprechend Maximalwerte. Bisher irritierte mich, dass bei mir max low privat und max low shared nicht 512 sondern 614MB ergibt (320+294). Auch max high privat und max high shared ergeben einen höheren Wert (896+841=1737) als VIRTUALADDRESSLIMIT-512 (1536-512=1024).
Demzufolge muss es das ja auch gar nicht.

Wenn ich das nun richtig verstehe wird ausgelagert sobald ein Wert den Maximalwert aus QSV_MAXxxxMEM erreicht bzw. die Summe (privat+shared) zu gross wird (512, bzw. VIRTUALADDRESSLIMIT-512)

Wenn in Deinem Beispiel Prozess B 400MB low privat anfordert, QSV_MAXxxxMEM aber für max low privat nur 320MB zurück gibt, würde dann eben bei mir 80MB ausgelagert? ...obwohl ich im low-Bereich noch genug Platz hätte? Dann würde der Prozess B bei mir den low shared Bereich für alle anderen Prozesse aber auf 192MB (512-320) belassen?

Ich versteh auch nicht die Ausgabe von QSV_TOTPHYSMEM mit 3GB.
Erkennt OS/2 lediglich 3GB physischen Speicher kann aber virtuell bis 4GB nutzen. Würde er dann im System-Bereich beim Erreichen von 1.5GB auch auslagern?

Nebenbei: bei mir ergab DLLBASING=OFF zusätzlich 77MB im low privat Bereich und etwa gleichviel im low shared Bereich.
Von MEMMAN=SWAP,PROTECT nach MEMMAN=SWAP,NOPROTECT,NOPACK verringerte sich der low shared Bereich um ca. 23MB.

Gruss Rolf
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Rolf hat geschrieben: Di 24. Sep 2019, 12:05 Bisher irritierte mich, dass bei mir max low privat und max low shared nicht 512 sondern 614MB ergibt (320+294). Auch max high privat und max high shared ergeben einen höheren Wert (896+841=1737) als VIRTUALADDRESSLIMIT-512 (1536-512=1024).
Die Werte sind nur als Richtewerte zu verstehen. Zitat aus der CPRef: "This number is advisory and is not guaranteed, since system conditions change constantly."
Rolf hat geschrieben: Di 24. Sep 2019, 12:05 Wenn ich das nun richtig verstehe wird ausgelagert sobald ein Wert den Maximalwert aus QSV_MAXxxxMEM erreicht bzw. die Summe (privat+shared) zu gross wird (512, bzw. VIRTUALADDRESSLIMIT-512)
Mit Auslagern hat das nichts zu tun. Wenn der Abstand zwischen den private und shared Arenen zu klein wird, dann hat das System ein echtes Problem! Dann werden beliebige Programm - inclusive der WPS - Fehlverhalten zeigen, hängenbleiben oder gar abstürzen. Völlig gleichgültig, wieviel physischer Speicher vorhanden ist.
Rolf hat geschrieben: Di 24. Sep 2019, 12:05 Wenn in Deinem Beispiel Prozess B 400MB low privat anfordert, QSV_MAXxxxMEM aber für max low privat nur 320MB zurück gibt, würde dann eben bei mir 80MB ausgelagert?
Nein. Ausgelagert wird, wenn die Summe des von allen Prozessen zusammen verwendeten Speichers die Größe des physischen Speichers überschreitet.
Rolf hat geschrieben: Di 24. Sep 2019, 12:05Ich versteh auch nicht die Ausgabe von QSV_TOTPHYSMEM mit 3GB. Erkennt OS/2 lediglich 3GB physischen Speicher...
Ja. Da im PC noch andere Hardwarekomponenten (Graphik, PCI-Karten, die CPU selbst) physische Adressen benötigen, wird für eine 32bittiges System kaum mehr als 3.5GB nutzbar sein.
Rolf hat geschrieben: Di 24. Sep 2019, 12:05 ...aber virtuell bis 4GB nutzen.
Der virtuelle Adressraum eines jeden Prozeßes ist in der Tat 4GB groß. Aber der überwiegende Teil davon ist normalerweise nicht mit physischem Speicher hinterlegt. Stell' Dir das vor wie eine Hängebrücke, bei der nur die Seile gespannt sind, die Fahrbahn aber fehlt. Wenn ein Programm nun todesmutig auf eine leere Stelle zufährt (auf eine "uncommitted" Page zugreift), kommen plötzlich Bauarbeiter und hängen blitzartig ein Stück Fahrbahn (sprich eine Page physischen Speichers) ein. Uff, nochmal gutgegangen! Nun gibt es aber nicht nur einen Prozeß, sondern viele. D.h. auch viele halbfertige Brücken. Und es kann passieren, daß den Bauarbeitern die Fahrbahnstücke ausgehen (physicher Speicher voll). Dann suchen sie irgend ein bestehendes Fahrbahnstück, das lange niemand benutzt hat, packen was auch immer darauf lag bei Seite (Pagefile), putzen es und hängen es an die benötigte Stelle ein. Natürlich fehlt es jetzt an der anderen Stelle. Falls es unschöner Weise dort wieder benötigt wird, muß ein anderes freigeschaufelt, mit den abgelegten Daten befüllt und wieder eingehängt werden. Das nennt sich dann "paging".
Rolf hat geschrieben: Di 24. Sep 2019, 12:05 Nebenbei: bei mir ergab DLLBASING=OFF zusätzlich 77MB im low privat Bereich und etwa gleichviel im low shared Bereich.
Von MEMMAN=SWAP,PROTECT nach MEMMAN=SWAP,NOPROTECT,NOPACK verringerte sich der low shared Bereich um ca. 23MB.
Mit den Parametern kenne ich mich nicht so aus. Zu neu...
Antworten