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.
Antworten
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

4 Kerne erkannt - wie kann das sein?

Beitrag von DonLucio »

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
Benutzeravatar
MikeK
Beiträge: 369
Registriert: Mo 23. Dez 2013, 13:51
Wohnort: Potsdam

Beitrag von MikeK »

Hallo,
OS/2, eCS & AOS sind entsprechenden Kernel vorausgesetzt Multiprozessor / Multicore fähig. Und das schon seit PentiumPro-Zeiten.
Grüße,
Mike
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

MikeK hat geschrieben: Mi 17. Okt 2018, 19:10OS/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.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

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
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

DonLucio hat geschrieben: Mi 17. Okt 2018, 23:36
MikeK hat geschrieben: Mi 17. Okt 2018, 19:10OS/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.
Zuletzt geändert von erdmann am Do 18. Okt 2018, 10:36, insgesamt 1-mal geändert.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

erdmann hat geschrieben: Do 18. Okt 2018, 10:35Allerdings 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.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

ehemaliger hat geschrieben: Sa 20. Okt 2018, 13:04
erdmann hat geschrieben: Do 18. Okt 2018, 10:35Allerdings 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
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

ak120 hat geschrieben: So 21. Okt 2018, 12:03Das 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.
Zuletzt geändert von ehemaliger am So 21. Okt 2018, 14:22, insgesamt 1-mal geändert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

ak120 hat geschrieben: So 21. Okt 2018, 12:03
ehemaliger hat geschrieben: Sa 20. Okt 2018, 13:04
erdmann hat geschrieben: Do 18. Okt 2018, 10:35Allerdings 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).
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

erdmann hat geschrieben: So 21. Okt 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
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

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.
Zuletzt geändert von erdmann am Mo 22. Okt 2018, 15:48, insgesamt 1-mal geändert.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

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...
Zuletzt geändert von ehemaliger am Sa 27. Okt 2018, 13:40, insgesamt 1-mal geändert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

ehemaliger hat geschrieben: Sa 27. Okt 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.
Antworten