Linux vs. Windows (Split aus: Allgemeine Funktion um verfügbaren Speicher zu ermitteln?)

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

https://www.pcwelt.de/a/gaming-benchmark-linux-vs-windows-10,3403023

SeppJ

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

hustbaer

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Das "Mist ich hab' was versprochen was ich jetzt nicht halten kann" Problem vermeidet Windows ja, indem es eben nix verspricht was es nicht halten kann.
(Also wenn wir mal ganz krasse Sachen wie IO Fehler beim Paging ignorieren.)
Und daher braucht es natürlich auch keinen Notfallplan für solche Fälle.

hustbaer

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Ansonsten hat man einen Vergleich Direct3D vs. OGL/Vulkan. Und den gewinnt im Moment Direct3D. Woran das liegt kann ich nicht sagen. Kann natürlich dran liegen dass das D3D Backend der Game Engines besser optimiert ist als das Vulkan Backend. Kann aber auch sein dass einfach die D3D Treiber besser sind.

SeppJ

hustbaer schrieb:

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Heißt das, das System ist dann für immer blockiert, weil man den Verursacher nicht abschießen kann? Weil man den Taskmanager/Konsole wegen Speichermangels nicht starten kann.

Ich könnte also ein Windowssystem mit

while(True) calloc(1, 1);

mit einem Schlag lahmlegen? Das ist ja schon ziemlich nahe dran an dem, was jemand im Ursprungthread zur Speichervermessung vorgeschlagen hatte. Ein paar Zeichen vertippt und er hätte dies gehabt. Es finde es nicht so weit hergeholt, dass es Programme gibt, die eine bad_alloc abfangen und sich dann eben nicht sofort beenden.

hustbaer schrieb:

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Und das Grafikframework ist das einzige, was zählt? Absolut kein Zusammenhang dazu, wie die Daten in das Framework kommen, wie das Framework genau konfiguriert ist, oder zum sonstigen Drumherum? Es gab mal einen tollen Artikel, ich glaube auf Heise, aber eventuell war es auch Golem, wie Valve ihre Sourceengine nach Linux portiert haben. Da standen viele solche Probleme beschrieben, und wie sie aus der lahmen direkten Portierung mit ein paar einfachen Anpassungen eine spielbare erste Version machten. Und die Entwickler erklärten, wie man solche Optimierungen natürlich umgekehrt auch machte, als man die Engine überhaupt das erste Mal für Windows entwickelt hat. Ich finde ihn leider nicht, aber es klang alles recht plausibel. Da ich selber nur interessierter Laie auf dem Gebiet von Hochleistungsspieleengines bin (und ich erlaube mir auch mal die Vermutung, dass dies für dich ebenfalls gilt), bin ich geneigt, denen, die so etwas tatsächlich beruflich entwickeln eher zu glauben, als der "müsste doch"-Einschätzung eines Außenstehenden.

Mechanics

SeppJ schrieb:

Ich könnte also ein Windowssystem mit
while(True) calloc(1, 1);
mit einem Schlag lahmlegen?

Ich glaub schon, mehr oder weniger. Das ist anscheinend von Version zu Version unterschiedlich und ich hatte mir erhlich gesagt nicht die Mühe gemacht, mich intensiv damit zu befassen. Aber ich hab vor einer Weile mal ausprobiert, was passiert, wenn ein Programm zu viel Speicher anfordert. Dann war erstmal das ganze System lahm und ich habs irgendwann nach Minuten geschafft, den Task Manager zu starten und den Prozess wieder zu killen. Danach hatte sich das System nach und nach wieder gefangen.

SeppJ

Dann müsste ja irgendetwas wieder frei geworden sein, damit du den Taskmanager starten konntest. Oder du hast Glück gehabt, dass ein anderes Programm an Speichermangel gestorben ist und dann korrekt freigegeben hat. Ansonsten könnte einer der am weitesten verbreiteten Programmierfehler überhaupt, das Speicherleck, das gesamte System lahmlegen. Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

SeppJ schrieb:

Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

Wobei man die Schleife unter Linux auch nur leicht abaendern muesste:

for (;;) fork();

Und es stellt sich die Frage, inwieweit man allgemein vor solchen Angriffen gewappnet sein muss (da wo es drauf ankommt, gibt es ja Loesungen fuer Linux und vermutlich auch fuer Windows).

Das Prozess-Abschiessen bei OOM, finde ich aber durchaus angebracht. Einfach gar nichts machen ist jedenfalls kaum besser.

SeppJ

Forkstackerdriver schrieb:

SeppJ schrieb:

Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

Wobei man die Schleife unter Linux auch nur leicht abaendern muesste:
for (;;) fork();

Naja. Ersten bringt das auch Windows zum Erliegen und zweitens und viel wichtiger: Wie viele Programme haben unabsichtliche Speicherlecks und wie viele haben unabsichtliche Threadlecks? Dass man mit einem bösartigen Schadprogramm und den nötigen Rechten einigen Unfug treiben kann, ist wohl außer Frage und gilt systemunabhängig.

Tja, das Speicherleck ist sicher häufiger, aber bis es zu einem Problem wird, vergeht dafür erstmal Zeit.

Ich habe unter Linux schon beides erlebt: OOM-Kills und Prozesse die Amok forken.

Windows hat ja für das Problem, dass Programme über längere Zeit zu viel Speicher reservieren, mittlerweile noch eine andere Lösung gefunden.
Siehe dazu https://www.c-plusplus.net/forum/344206

*SCNR*, mfg, Uptimer

SeppJ

Forkstackerdriver schrieb:

Windows hat ja für das Problem, dass Programme über längere Zeit zu viel Speicher reservieren, mittlerweile noch eine andere Lösung gefunden.
Siehe dazu https://www.c-plusplus.net/forum/344206

*SCNR*, mfg, Uptimer

lol. Das akzeptiere ich fortan als die beste Art und Weise, ein System stets zuverlässig zu halten

hustbaer

SeppJ schrieb:

hustbaer schrieb:

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Heißt das, das System ist dann für immer blockiert, weil man den Verursacher nicht abschießen kann? Weil man den Taskmanager/Konsole wegen Speichermangels nicht starten kann.

Ich könnte also ein Windowssystem mit
while(True) calloc(1, 1);
mit einem Schlag lahmlegen? Das ist ja schon ziemlich nahe dran an dem, was jemand im Ursprungthread zur Speichervermessung vorgeschlagen hatte. Ein paar Zeichen vertippt und er hätte dies gehabt. Es finde es nicht so weit hergeholt, dass es Programme gibt, die eine bad_alloc abfangen und sich dann eben nicht sofort beenden.

Möglich. Allerdings verwende ich nun schon wirklich lange Windows, und seit ich Rechner mit > 4 GB RAM habe kann ich mich an keine solche Situation erinnern. Ist also eher ein theoretisches Problem. Also schon eines das man in der Praxis vermutlich ganz einfach absichtlich herbeiführen kann, aber eines das halt ansonsten kaum auftritt.

Jetzt direkt hab' ich keine Zeit, aber wenn ich heute später nochmal dran denke werd' ich das ausprobieren. Gibt ja schliesslich fertige Tools die genau dafür gemacht sind "out of memory" Conditions zu produzieren - zum Testen wie stabil Programme unter solchen Umständen laufen. Hab' ich erst letztens in der Arbeit gemacht. Dabei hab' ich den Speicherfresser allerdings mit Ctrl+C abgebrochen (hatte ein Kommandozeilenprogramm verwendet). Daher weiss ich nicht ob man es schafft dann noch den Task-Manager aufzumachen.

SeppJ schrieb:

hustbaer schrieb:

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Und das Grafikframework ist das einzige, was zählt? Absolut kein Zusammenhang dazu, wie die Daten in das Framework kommen, wie das Framework genau konfiguriert ist, oder zum sonstigen Drumherum? Es gab mal einen tollen Artikel, ich glaube auf Heise, aber eventuell war es auch Golem, wie Valve ihre Sourceengine nach Linux portiert haben. Da standen viele solche Probleme beschrieben, und wie sie aus der lahmen direkten Portierung mit ein paar einfachen Anpassungen eine spielbare erste Version machten. Und die Entwickler erklärten, wie man solche Optimierungen natürlich umgekehrt auch machte, als man die Engine überhaupt das erste Mal für Windows entwickelt hat. Ich finde ihn leider nicht, aber es klang alles recht plausibel. Da ich selber nur interessierter Laie auf dem Gebiet von Hochleistungsspieleengines bin (und ich erlaube mir auch mal die Vermutung, dass dies für dich ebenfalls gilt), bin ich geneigt, denen, die so etwas tatsächlich beruflich entwickeln eher zu glauben, als der "müsste doch"-Einschätzung eines Außenstehenden.

Wäre interessant was das für Anpassungen waren. Hast du zufällig den Link zu dem Aritkel noch? Würde mich interessieren.

Mir fällt halt nicht wirklich etwas ein, was man unter Linux anders machen müsste als unter Windows. Also speziell bei dem was Spiele so machen. Kann natürlich sein dass ich mich da verschätze - gerade deswegen wäre ja der Artikel interessant.

hustbaer

Forkstackerdriver schrieb:

Und es stellt sich die Frage, inwieweit man allgemein vor solchen Angriffen gewappnet sein muss (da wo es drauf ankommt, gibt es ja Loesungen fuer Linux und vermutlich auch fuer Windows).

Das Prozess-Abschiessen bei OOM, finde ich aber durchaus angebracht. Einfach gar nichts machen ist jedenfalls kaum besser.

Für mich stellen sich zwei Fragen.
Erstmal was du schon schreibst, also ob es überhaupt nötig ist eine fest eingebaute Lösung für solche Fälle zu haben, die ohne vorherige Konfiguration und/oder Zutun des Benutzers etwas unternimmt.

Und dann: was sollte in so einem Fall sinnvollerweise unternommen werden? Ich finde es auf jeden Fall sehr fragwürdig einfach anhand irgend einer Metrik einen oder mehrere Prozesse auszuwählen und diese dann zu killen. Dann lieber noch das ganze System neu starten. Das aber bitte auch nur als opt-in. Für die meisten Server wäre das IMO die bessere Variante. Denn durch Wegschiessen irgendwelcher Prozesse kann man Server recht leicht in einen Zustand versetzen wo sie zwar ewig weiterlaufen werden und auch kein "out of memory" mehr produzieren werden, aber die gehostete Anwendung einfach nicht mehr funktioniert. Was ich ehrlich gesagt nicht so sexy finde.

Gibt auch einige Interessante Beiträge dazu, z.B.:
http://thoughts.davisjeff.com/2009/11/29/linux-oom-killer/

Ich weiss nicht ob die "badness" Metrik diesbezüglich schon gefixt wurde. Aber das was da beschrieben ist liest sich für mich nicht so prickelnd.

hustbaer schrieb:

Ansonsten hat man einen Vergleich Direct3D vs. OGL/Vulkan. Und den gewinnt im Moment Direct3D. Woran das liegt kann ich nicht sagen. Kann natürlich dran liegen dass das D3D Backend der Game Engines besser optimiert ist als das Vulkan Backend. Kann aber auch sein dass einfach die D3D Treiber besser sind.

oder daran, dass die entwickler keine lust haben, ihren quellcode offen legen zu müssen und daher auf sog. Adapter-Pattern (heißt das so?) zurückgreifen müssen und jeder furz erst einmal durchgereicht und das ergebnis dann zurückgereicht werden muss, was eben Zeit kostet.

Jedenfalls habe ich mir das in Bezug auf binäre Linux-Kernel-Treiber so erklären lassen und Direct3D kann ja vom Compiler entsprechend in Treiber-Funktionen oder was auch immer umgewandelt werden, denke ich mal.

hustbaer schrieb:

Und dann: was sollte in so einem Fall sinnvollerweise unternommen werden? Ich finde es auf jeden Fall sehr fragwürdig einfach anhand irgend einer Metrik einen oder mehrere Prozesse auszuwählen und diese dann zu killen. Dann lieber noch das ganze System neu starten. Das aber bitte auch nur als opt-in. Für die meisten Server wäre das IMO die bessere Variante. Denn durch Wegschiessen irgendwelcher Prozesse kann man Server recht leicht in einen Zustand versetzen wo sie zwar ewig weiterlaufen werden und auch kein "out of memory" mehr produzieren werden, aber die gehostete Anwendung einfach nicht mehr funktioniert. Was ich ehrlich gesagt nicht so sexy finde.

Gibt auch einige Interessante Beiträge dazu, z.B.:
http://thoughts.davisjeff.com/2009/11/29/linux-oom-killer/

Ich weiss nicht ob die "badness" Metrik diesbezüglich schon gefixt wurde. Aber das was da beschrieben ist liest sich für mich nicht so prickelnd.

Ich setze bei den OOM-Kills schon voraus, dass man geziehlt bestimmte Prozesse davon ausschliessen kann.
Habe mal den ersten google-Treffer herausgesucht: http://elixir.free-electrons.com/linux/v4.1/source/mm/oom_kill.c#L140
Da gibt es auf jeden fall bool unkillable_task() .

PostgreSQL ist womoeglich ein Kandidat dafuer.

Ein anderer Kandidat waere ein logging-Daemon, achja und natuerlich jeder andere Prozess, der das System am Leben haelt. Ein Neustart ist dir echt lieber als das nur ein Prozess gekillt wird? (Ich denke i.d.R. ist das ja auch der Problemprozess)

hustbaer

Forkstackerdriver schrieb:

Ich setze bei den OOM-Kills schon voraus, dass man geziehlt bestimmte Prozesse davon ausschliessen kann.
Habe mal den ersten google-Treffer herausgesucht: http://elixir.free-electrons.com/linux/v4.1/source/mm/oom_kill.c#L140
Da gibt es auf jeden fall bool unkillable_task() .

Wo, "da"?

Forkstackerdriver schrieb:

PostgreSQL ist womoeglich ein Kandidat dafuer.

Ein anderer Kandidat waere ein logging-Daemon, achja und natuerlich jeder andere Prozess, der das System am Leben haelt.

Kandidat für was?

Forkstackerdriver schrieb:

Ein Neustart ist dir echt lieber als das nur ein Prozess gekillt wird? (Ich denke i.d.R. ist das ja auch der Problemprozess)

Ja, weil nach einem Neustart normalerweise alles wieder startet was nötig ist. Wenn man einfach so Prozesse wegschiesst garantiert mir das keiner.

hustbaer schrieb:

Forkstackerdriver schrieb:

Ich setze bei den OOM-Kills schon voraus, dass man geziehlt bestimmte Prozesse davon ausschliessen kann.
Habe mal den ersten google-Treffer herausgesucht: http://elixir.free-electrons.com/linux/v4.1/source/mm/oom_kill.c#L140
Da gibt es auf jeden fall bool unkillable_task() .

Wo, "da"? [...] Kandidat für was?

na da, gleich am Anfang in der verlinkten Funktion wird auf unkillable_task getestet. Aber ich bin kein Kernelprogrammierer. Bin wie gesagt davon ausgegangen, dass man da Einfluss nehmen kann.

Kandidat um in die Liste an Prozessen aufgenommen zu werden, die nicht "einfach" so gekillt werden.
Wenn entsprechende wichtige Prozesse am Leben bleiben, können auch die Fehlerhaften Prozess einfach neu gestartet werden. Dazu braucht es keinen Systemreset.

SeppJ schrieb:

Ich könnte also ein Windowssystem mit
while(True) calloc(1, 1);
mit einem Schlag lahmlegen?

Nette Idee Ich habs letzten Freitag bei der Arbeit mal ausprobiert und Win10 damit zum Stillstand gebracht.

Es wäre interessant, das Experiment mit einem Rechner ohne Pagefile zu wiederholen, ich vermute nämlich, daß der Stillstand daher rührt, daß Windows zum Schluß nur noch mit Paging beschäftigt ist (was bei diesem Rechner besonders schwerwiegend ist, da er noch eine HDD verwendet).

SeppJ schrieb:

Wie viele Programme haben unabsichtliche Speicherlecks und wie viele haben unabsichtliche Threadlecks?

Ob dein Programm ein Speicherleck hat, oder ob es unerbittlich und von fehlschlagenden Allokationen unbeeindruckt jeden freiwerdenden Speicherblock absorbiert, ist ja wohl ein Unterschied. Und Windows ist durchaus in der Lage, gewöhnliche Speicherknappheit zu erkennen, und zeigt dann eine Warnmeldung an, die auch anbietet, den Speicherfresser zu terminieren: https://i.stack.imgur.com/HkjXK.png.

Durch dieses Verhalten erklärt sich auch meine Erfahrung, daß man (Desktop-)Windows besser mit Pagefile betreiben sollte, besonders wenn man nur 3 oder 4 GB RAM im Rechner hat (was an sich für sehr viele Anwendungsfälle vollkommen ausreicht). Solange ein Pagefile da ist, ist Overcommitting kein Problem, aber andernfalls sieht man öfters solche Dialoge oder gar Fehlverhalten von Programmen, die mit out-of-memory nicht zurechtkommen.

hustbaer

Forkstackerdriver schrieb:

hustbaer schrieb:

Forkstackerdriver schrieb:

Ich setze bei den OOM-Kills schon voraus, dass man geziehlt bestimmte Prozesse davon ausschliessen kann.
Habe mal den ersten google-Treffer herausgesucht: http://elixir.free-electrons.com/linux/v4.1/source/mm/oom_kill.c#L140
Da gibt es auf jeden fall bool unkillable_task() .

Wo, "da"? [...] Kandidat für was?

na da, gleich am Anfang in der verlinkten Funktion wird auf unkillable_task getestet. Aber ich bin kein Kernelprogrammierer. Bin wie gesagt davon ausgegangen, dass man da Einfluss nehmen kann.

Meinst du oom_unkillable_task ? Die Implementierung davon steht direkt über der von dir verlinkten. Ich sehe da nix was für mich so aussieht als ob man da seinen Prozess irgendwie "registrieren" könnte.

Forkstackerdriver schrieb:

Kandidat um in die Liste an Prozessen aufgenommen zu werden, die nicht "einfach" so gekillt werden.
Wenn entsprechende wichtige Prozesse am Leben bleiben, können auch die Fehlerhaften Prozess einfach neu gestartet werden. Dazu braucht es keinen Systemreset.

Naja...
Wenn das Programm selbst sagen kann "ich darf nicht OOK-gekillt werden", dann ist der OOM-Killer auch wieder für die Würste. Dann hast du den Bug nämlich in einem Programm welches, weil der Programmierer ja sooooooo schlau war, sich als "darf nicht OOK-gekillt werden" flaggt, aber trotzdem ein böses Leak enthält.
Und wenn es eine vom Sysop definierte Liste gibt, dann hast du quasi das selbe Problem, nämlich dass der Sysop sich für schlau hält und ein Programm einträgt dass dann doch wieder leakt.

Der OOM Killer bringt also vielleicht für Desktops 'was, wenn man davon ausgeht dass der Benutzer schlau genug ist nicht stundenlang Fehler zu suchen nur weil der OOM-Killer ihm was weggeschossen hat. Weil der PC dann bedienbar bleibt und er nicht alle ungespeicherten Daten verliert. Für Server aber IMO eher nicht, weil es IMO recht viel Aufwand ist das System so zu konfigurieren, dass alles immer zuverlässig neu gestartet wird wenn es OOM-weggeschossen wird.
Speziell auf Windows wo man nicht einfach "starte das Service neu" in den Service-Optionen reinklickt wenn man möchte dass ein Service im Fehlerfall neu gestartet wird. Wenn man Glück hat bringt das service nen eigenen Watchdog mit. Und wenn nicht, dann darf man selbst Bashen oder sonstwas. Und dann natürlich alle Varianten testen, also alle möglichen Reihenfolgen in denen einer (oder mehrere) der 20 Prozesse die man in "modernen" Anwendungsstacks so braucht weggeschossen und dann neu gestartet werden. Hui.

Die robustere Variante ist da IMO echt einfach die ganze Kiste durchzustarten.