4 Kerne erkannt - wie kann das sein?

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
User avatar
DonLucio
Posts: 334
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

4 Kerne erkannt - wie kann das sein?

Post by DonLucio » Wed 17. Oct 2018, 16:15

Seit ich ArcaOS 5.0.2 auf meinem System habe, meldet mir der Bootloader: "Processors detected: 4".

Das ist im Prinzip ja auch richtig (habe eine Quadcore-CPU). Aber macht das Sinn? Afaik gibt es im ArcaOS-Kernel keine mehrprozessorfähigen Routinen. Ebensowenig wären mir Anwendungen bekannt, die mehr als 1 CPU nutzen können.

Ich verstehe ja nicht viel von diesen Multicore-Architekturen. Aber ein Gefühl sagt mir, dass es für ein Singleprozessor-OS nur eine Ballast darstellt, wenn es "denkt", da gibt es aber 4.

Konkrete Frage: Kann man die Multicore-Erkennung abschalten bzw. dem ArcaOS sagen, es möge so tun, als ob es nur 1 Core gäbe?

Danke,
Lutz Wagner

User avatar
MikeK
Posts: 203
Joined: Mon 23. Dec 2013, 13:51
Location: Potsdam

Post by MikeK » Wed 17. Oct 2018, 19:10

Hallo,
OS/2, eCS & AOS sind entsprechenden Kernel vorausgesetzt Multiprozessor / Multicore fähig. Und das schon seit PentiumPro-Zeiten.
Grüße,
Mike

User avatar
DonLucio
Posts: 334
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Wed 17. Oct 2018, 23:36

MikeK wrote:
Wed 17. Oct 2018, 19:10
OS/2, eCS & AOS sind entsprechenden Kernel vorausgesetzt Multiprozessor / Multicore fähig. Und das schon seit PentiumPro-Zeiten
Oh, da muß ich mich wohl korrigieren. Habe soeben festgestellt, dass der Firefox 45.9.0 tatsächlich alle 4 Kerne benutzt.

Sorry, aber ich war der festen Meinung, dass es für Multiprozessor-Unterstützung seinerzeit eine extra-OS/2-Version gab, die ziemlich teuer war und auch nur bei wenigen großen Firmen im Einsatz. Aber da habe ich mich wohl geirrt..

Ziehe damit diesen Thread zurück.

Danke für die Aufklärung.
Lutz W.

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

Post by aschn » Thu 18. Oct 2018, 01:51

Mehrere Kerne bringen im Multi-Threading- oder Multi-Tasking-Betrieb immer eine Verbesserung. Die Anwendungen müssen nicht extra dafür kompiliert werden. Wie die Leistung auf die Kerne aufgeteilt wird, kann aber bei den Betriebssystemen unterschiedlich sein.

Multi-Threading: Innerhalb einer Anwendung laufen mehrere Prozesse. Das z.B. zur Folge haben, dass auf Benutzeraktionen reagiert wird, obwohl z.B. gerade eine Listbox gefüllt oder eine Datei heruntergeladen wird.
Andreas Schnellbacher

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

Post by erdmann » Thu 18. Oct 2018, 10:35

DonLucio wrote:
Wed 17. Oct 2018, 23:36
MikeK wrote:
Wed 17. Oct 2018, 19:10
OS/2, eCS & AOS sind entsprechenden Kernel vorausgesetzt Multiprozessor / Multicore fähig. Und das schon seit PentiumPro-Zeiten
Oh, da muß ich mich wohl korrigieren. Habe soeben festgestellt, dass der Firefox 45.9.0 tatsächlich alle 4 Kerne benutzt.

Sorry, aber ich war der festen Meinung, dass es für Multiprozessor-Unterstützung seinerzeit eine extra-OS/2-Version gab, die ziemlich teuer war und auch nur bei wenigen großen Firmen im Einsatz. Aber da habe ich mich wohl geirrt..

Ziehe damit diesen Thread zurück.

Danke für die Aufklärung.
Lutz W.
Sie denken da sicherlich an OS/2 2.1 SMP. Das war in der Tat eine spezielle Version in der Hinsicht dass sie voll SMP fähig war, was heißen soll, dass auch die Interrupt Verarbeitung auf jedem der vorhandenen Kerne stattfinden konnte. Allerdings hat IBM dann schnell festgestellt dass viele HW Treiber dafür nicht ausgelegt waren so dass sie viele hätten neu schreiben müssen. Deshalb haben sie diesen Ansatz aufgegeben.

Nichtsdestotrotz kann das heutige OS/2 SMP auf mehreren Kernen arbeiten, egal ob nun mehrere Threads derselben Applikation auf mehreren Kernen parallel laufen oder mehrere Applikationen mit nur einem Thread auf diese Kerne parallel verteilt werden. Nur die Interrupt Verarbeitung findet lediglich auf einem festgelegten Kern statt was allerdings im Vergleich zu einer voll SMP fähigen Lösung auch etwas an Performance kostet.
Als Vorteil dieser Lösung funktionieren jedoch die allermeisten der HW Treiber die ja mal für ein Einkernsystem geschrieben wurden immer noch.
Last edited by erdmann on Thu 18. Oct 2018, 10:36, edited 1 time in total.

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

Post by ehemaliger » Sat 20. Oct 2018, 13:04

erdmann wrote:
Thu 18. Oct 2018, 10:35
Allerdings hat IBM dann schnell festgestellt dass viele HW Treiber dafür nicht ausgelegt waren so dass sie viele hätten neu schreiben müssen. Deshalb haben sie diesen Ansatz aufgegeben.
Ein weiteres Beispiel für eine eklatante Fehlentscheidung/Kurzsichtigkeit von Seiten IBM. Als sich diese Probleme abzeichneten wäre der richtige Zeitpunkt gewesen, das archaische Gerätetreibermodell über Bord zu werfen und etwas generell neues einzuführen. Aber man fürchtete die Investitionen und argumentierte, daß doch niemand SMP brauchen würde.

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

Post by ak120 » Sun 21. Oct 2018, 12:03

ehemaliger wrote:
Sat 20. Oct 2018, 13:04
erdmann wrote:
Thu 18. Oct 2018, 10:35
Allerdings hat IBM dann schnell festgestellt dass viele HW Treiber dafür nicht ausgelegt waren so dass sie viele hätten neu schreiben müssen. Deshalb haben sie diesen Ansatz aufgegeben.
Ein weiteres Beispiel für eine eklatante Fehlentscheidung/Kurzsichtigkeit von Seiten IBM. Als sich diese Probleme abzeichneten wäre der richtige Zeitpunkt gewesen, das archaische Gerätetreibermodell über Bord zu werfen und etwas generell neues einzuführen. Aber man fürchtete die Investitionen und argumentierte, daß doch niemand SMP brauchen würde.
Es mag ja für einige Leute interessant sein, hier Ihre Theorien zu verbreiten. Aber wie so oft hat es wenig mit den nachvollziehbaren Fakten zu tun. Für keine dieser Behauptungen ist auch nur ansatzweise ein Beleg oder Nachweis erbracht worden. Da werden Programmprodukte erfunden, welche es in dieser Form nie gegeben hat und völlig hanebüchene Zusammenhänge hergestellt. Multiprozessorunterstützung gibt es von IBM seit mindestens 45 Jahren. Bezüglich OS/2 1.3 gab es ab Herbst 1992 (siehe ZP92-0718) die IBM Multi Processing Extensions/2, welche auf dem PS/2 Server 295 mit 2 Prozessoren eingesetzt werden konnte. Wie es sich damit ab August 1993 unter OS/2 2.1 verhielt, kann unter ZP93-0602 nachvollzogen werden.
Das erste Produkt mit MPS1.1-Unterstützung war IBM OS/2 for Symmetrical Multiprocessing Version 2.11 (ZP94-0432).

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

Post by ehemaliger » Sun 21. Oct 2018, 13:29

ak120 wrote:
Sun 21. Oct 2018, 12:03
Das erste Produkt mit MPS1.1-Unterstützung war IBM OS/2 for Symmetrical Multiprocessing Version 2.11 (ZP94-0432).
Genau dieses Produkt erforderte spezielle, SMP-fähige Treiber und lief nur auf sehr ausgewählter Hardware. Doch anstelle diese Technologie strategisch weiterzuentwickeln, machte IBM einen Rückzieher und kastrierte die späteren SMP-Kernels bezüglich der Interruptverarbeitung. Was im Übrigen bedeutet, daß während der Bearbeitung eines Interrupts durch CPU0 alle anderen CPUs/Kerne in einem Spinlock festhängen und 100% Last produzieren ohne eine sinnvolle Aufgabe zu erfüllen. Als SMP-Hardware gebräuchlicher wurde und Microsoft entsprechende Unterstützung "out-of-the box" anbot, war IBMs Ausrede, daß man das - wenn überhaupt - nur für Server brauchen würde. Da man aber die Weiterentwicklung des Kernels verschlafen/eingespart hatte, mußten selbst im Serverbereich Hacks (z.B. die partielle Parallelverarbeitung innerhalb von JFS, wobei aber die Aufrufe in den Disk-Treiber selbst mittels entsprechender KEE-Funktionen serialisiert werden) herhalten, um die Hardware wenigstens teilweise ausnutzen zu können. Um es nochmal ganz klar zu sagen: Alle SMP-Kernels nach 2.11 waren aus technologischer Sicht ein Rückschritt und KEE ein halbherziger Versuch bisherige Versäumnisse zu kaschieren.
Last edited by ehemaliger on Sun 21. Oct 2018, 14:22, edited 1 time in total.

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

Post by erdmann » Sun 21. Oct 2018, 19:51

ak120 wrote:
Sun 21. Oct 2018, 12:03
ehemaliger wrote:
Sat 20. Oct 2018, 13:04
erdmann wrote:
Thu 18. Oct 2018, 10:35
Allerdings hat IBM dann schnell festgestellt dass viele HW Treiber dafür nicht ausgelegt waren so dass sie viele hätten neu schreiben müssen. Deshalb haben sie diesen Ansatz aufgegeben.
Ein weiteres Beispiel für eine eklatante Fehlentscheidung/Kurzsichtigkeit von Seiten IBM. Als sich diese Probleme abzeichneten wäre der richtige Zeitpunkt gewesen, das archaische Gerätetreibermodell über Bord zu werfen und etwas generell neues einzuführen. Aber man fürchtete die Investitionen und argumentierte, daß doch niemand SMP brauchen würde.
Es mag ja für einige Leute interessant sein, hier Ihre Theorien zu verbreiten. Aber wie so oft hat es wenig mit den nachvollziehbaren Fakten zu tun. Für keine dieser Behauptungen ist auch nur ansatzweise ein Beleg oder Nachweis erbracht worden. Da werden Programmprodukte erfunden, welche es in dieser Form nie gegeben hat und völlig hanebüchene Zusammenhänge hergestellt. Multiprozessorunterstützung gibt es von IBM seit mindestens 45 Jahren. Bezüglich OS/2 1.3 gab es ab Herbst 1992 (siehe ZP92-0718) die IBM Multi Processing Extensions/2, welche auf dem PS/2 Server 295 mit 2 Prozessoren eingesetzt werden konnte. Wie es sich damit ab August 1993 unter OS/2 2.1 verhielt, kann unter ZP93-0602 nachvollzogen werden.
Das erste Produkt mit MPS1.1-Unterstützung war IBM OS/2 for Symmetrical Multiprocessing Version 2.11 (ZP94-0432).
Ach wie ich diese selbstgefälligen Hirnausflüsse liebe. Ok, das Produkt hieß OS/2 2.11 SMP (verkürzt) und nicht OS/2 2.1 SMP.Ansonsten ist es genauso wie ich gesagt habe. Wie das Produkt OS/2 2.11 SMP funktioniert hat kann man in der Datei SMP.INF nachlesen. Wie das jetzige OS/2 SMP (Warp, Server bla) funktioniert hat Scott Garfinkle zum Teil in diversen Entwicklergruppen erklärt, zum Teil habe ich auch IBM Patente zum Thema gefunden die sich auf die jetzige OS/2 SMP Version beziehen. Aber sie wissen, wie wir alle hier im Forum bereits wissen, immer alles natürlich am besten (wahrscheinlich werden sie mir jetzt antworten das man "am Besten" und nicht "am besten" schreibt).

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

Post by ak120 » Mon 22. Oct 2018, 11:15

erdmann wrote:
Sun 21. Oct 2018, 19:51
Ach wie ich diese selbstgefälligen Hirnausflüsse liebe. Ok, das Produkt hieß OS/2 2.11 SMP (verkürzt) und nicht OS/2 2.1 SMP.Ansonsten ist es genauso wie ich gesagt habe. Wie das Produkt OS/2 2.11 SMP funktioniert hat kann man in der Datei SMP.INF nachlesen. Wie das jetzige OS/2 SMP (Warp, Server bla) funktioniert hat Scott Garfinkle zum Teil in diversen Entwicklergruppen erklärt, zum Teil habe ich auch IBM Patente zum Thema gefunden die sich auf die jetzige OS/2 SMP Version beziehen. Aber sie wissen, wie wir alle hier im Forum bereits wissen, immer alles natürlich am besten (wahrscheinlich werden sie mir jetzt antworten das man "am Besten" und nicht "am besten" schreibt).
Die Programmfunktionsbeschreibung entnehme ich doch lieber den entsprechenden Publikationen. Gemäß dem "IA-32 Intel Architecture Software Developer’s Manual Volume 3: System Programming Guide" (Kapitel 7 bis 9) waren gewisse Änderungen völlig plausibel. Praktisch kann ich es hier nur auf Doppelprozessorsystemen vergleichen. Es mag sein, daß für ein hypothetisches 8-Prozessor-System unter OS/2 2.11 SMP die mit Warp Server Advanced SMP eingeführten Änderungen nicht in allen Bereichen vorteilhaft gewesen sein könnten.

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

Post by erdmann » Mon 22. Oct 2018, 15:46

OS/2 2.11 SMP: funktioniert wie in SMP.INF erwähnt

Warp Server Advanced SMP: hier die zwei US Patente die erklären wie Interrupt Serialisierung bzw. die Serialisierung von Task- und Interrupt Code funktionieren (ich meine ich habe beide Patente bei Google Patents gefunden):
1) Interrupt Serialisierung: US5,560,018 (nach Datei US5560018.PDF im Internet suchen)
2) Serialisierung von Task- und Interrupt Code: US5,966,543 (nach Datei US5966543.PDF im Internet suchen)

Nr 1) wird dadurch bewiesen dass heutzutage das IOPL flag = 0 ist, im Gegensatz zu früheren Version von OS/2 (also vor OS/2 2.11 SMP und Warp Server Advanced SMP) wo IOPL=2 war und außerdem dadurch dass es im Kernelcode ein Spinlock namens "CLISpinLock" gibt. Das galt wahrscheinlich schon für OS/2 2.11 SMP und gilt nach wie vor für Warp Server Advanced SMP.

Nr 2) wird dadurch bewiesen dass es im Kernelcode zwei Spinlocks namens "R0SubSysSpinLock" (Task time) sowie "InterruptSpinLock" (interrupt time) gibt.

Es spielt überhaupt keine Rolle wieviel Prozessoren das System hat. Hier ist nichts hypothetisch, Warp Server Advanced SMP funktioniert anders als OS/2 2.11 SMP. Die Gründe warum man sich dann in Bezug auf Interrupt Handling für das Design entschieden hat welches in Warp Server Advanced SMP gewählt wurde sind im Patent 2) beschrieben.
Last edited by erdmann on Mon 22. Oct 2018, 15:48, edited 1 time in total.

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

Post by ehemaliger » Sat 27. Oct 2018, 12:02

Interessanter Fund. Erstaunlich, was man sich bei dem Amis so alles patentieren lassen kann. Ich hatte die Einschränkungen stärker in Erinnerung... Aber unterm Strich bleibt, daß Performance (Multiprocessing existiert praktisch nur für Applikationen, nicht aber für Gerätetreiber; E/A-Operationen mehrerer Programme werden stets nacheinander ausgeführt auch wenn sie verschiedene, voneinander unabhängige Geräte betreffen) der heiligen Kuh der Kompatibilität geopfert wurde anstelle auf eine echten Lösung für die Probleme (z.B. Definition eines neuen 32-bittigen Gerätetreibermodells wobei SMP-Kernels prinzipiell keine Alttreiber unterstützen und UNI-Kernels das nur während einer Übergangperiode tun) hinzuarbeiten. Aber das Management hat es wohl nicht anders gewollt...
Last edited by ehemaliger on Sat 27. Oct 2018, 13:40, edited 1 time in total.

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

Post by erdmann » Sat 27. Oct 2018, 18:43

ehemaliger wrote:
Sat 27. Oct 2018, 12:02
Interessanter Fund. Erstaunlich, was man sich bei dem Amis so alles patentieren lassen kann. Ich hatte die Einschränkungen stärker in Erinnerung... Aber unterm Strich bleibt, daß Performance (Multiprocessing existiert praktisch nur für Applikationen, nicht aber für Gerätetreiber; E/A-Operationen mehrerer Programme werden stets nacheinander ausgeführt auch wenn sie verschiedene, voneinander unabhängige Geräte betreffen) der heiligen Kuh der Kompatibilität geopfert wurde anstelle auf eine echten Lösung für die Probleme (z.B. Definition eines neuen 32-bittigen Gerätetreibermodells wobei SMP-Kernels prinzipiell keine Alttreiber unterstützen und UNI-Kernels das nur während einer Übergangperiode tun) hinzuarbeiten. Aber das Management hat es wohl nicht anders gewollt...
Gut zusammengefaßt.

Der Grund war derselbe wie schon bei der Entscheidung bei der Einführung von OS/2 2.0 bei 16-bittigen Gerätetreibern/Dateisystemtreibern zu bleiben: das Management hat sich nicht getraut den HW Drittanbietern zu sagen dass sie nun für ihre Geräte neue Treiber schreiben müssen (das was z.B. heutzutage Apple gnadenlos macht, und zwar auch in Hinsicht auf normale Applikationen).
Man muss sagen dass es in der Tat schwierig ist das durchzudrücken, vor allem wenn man so wie IBM Großkunden hat. Technisch gesehen war das die falsche Entscheidung aber politisch gesehen kann es die richtige gewesen sein, soll heißen, OS/2 wäre vielleicht schon längst weg vom Fenster wenn man 1995 anders entschieden hätte.