Thema: Threads blockieren und wieder aufwecken

[FlashBurn]

Um ehrlich zu sein glaube ich das nicht so wirklich, das erscheint mir irgendwie arg daneben, selbst für x86-Verhältnisse.

Wieso eigentlichen? Das Ding heißt nicht umsonst local-APIC. Der ist doch für die anderen CPUs total uninteressant und er ist direkt auf der CPU und mir ist jetzt nix bekannt, wie man direkt auf eine andere CPU von einer CPU aus, zugreifen kann. Zumal du ja auch nicht auf die Idee kommst, MSRs von anderen CPUs manipulieren zu wollen.

Gerade deswegen ist es IMHO eine sinnvolle Idee wenn das OS den Programmen ein paar Stellschrauben anbietet damit diese den Automatismus zumindest etwas auf die Sprünge helfen können.

Dafür sind mMn Prioritäten da. Zumal hieße das nicht auch, das man, im Falle des Bulldozers, die Programme extra dafür programmieren soll, weil der Scheduler unter Windows diese benachteiligt? Was hieße das für den Code?

trotzdem kann (nicht muss) die Umsetzung eines Workarounds durchaus dem KISS-Prinzip entsprechen

Pass auf, mein Problem ist einfach, wer legt fest ob solch ein Workaround noch dem KISS-Prinzip entspricht? Es scheint ja keine knallharten Kriterien zu geben nach denen jeder zum gleichen Ergebnis kommt. Von daher ist es halt subjektiv und nur darum geht es mir hier.

[erik.vikinger]

Hallo,

Wieso eigentlichen?

Weil es selbst für x86-Verhältnisse schon ziemlich strange ist das mehrere unterschiedliche Ressourcen hinter der selben physischen Speicheradresse stecken.

Zumal du ja auch nicht auf die Idee kommst, MSRs von anderen CPUs manipulieren zu wollen.

Doch, auf genau diese Idee bin ich gekommen. Bei meiner Plattform kann jede CPU auf die lokalen Controll-Register jeder anderen CPU zugreifen. Ohne dem könnte der Boot-Loader gar nicht die anderen CPUs finden und aktivieren (deswegen bin ich mir auch relativ sicher dass das auch bei x86 möglich ist). Auch andere nützliche Dinge lassen sich damit anstellen wenn jede CPU jeder anderen mal genau auf die Finger schauen kann.

Dafür sind mMn Prioritäten da.

Du hast doch selber festgestellt das dafür die Prioritäten alleine nicht ausreichen, die werden frühestens nach Ablauf der aktuellen Zeitscheibe wirksam, aber Du willst es doch schneller haben also musst Du auch zusätzliche Mechanismen einbauen (ob das festpinnen oder IPIs oder irgendwas anderes ist ist ja erstmal egal).

Zumal hieße das nicht auch, das man, im Falle des Bulldozers, die Programme extra dafür programmieren soll, weil der Scheduler unter Windows diese benachteiligt?

Ich weiß es nicht genau aber das die Bulldozers Probleme mit dem geteilten Cache haben wird wohl eher am gegenseitigen Verdrängen durch Aliasing liegen, dieses Problem hatte Intel mit den ersten P4's mit Hyperthreading auch, da kann der Scheduler vom OS gar nix gegen tun (hier könnte höchstens besseres ASLR helfen), sowas muss in der HW gefixt werden.

Von daher ist es halt subjektiv und nur darum geht es mir hier.

Alles ist letztendlich (zumindest teilweise) subjektiv, und persönliche Meinungen erst recht.


Grüße
Erik

[FlashBurn]

Ohne dem könnte der Boot-Loader gar nicht die anderen CPUs finden und aktivieren (deswegen bin ich mir auch relativ sicher dass das auch bei x86 möglich ist).

Also das BIOS weckt die CPUs genauso auf, wie das OS es später machen soll. Es wird eine (oder zwei) IPI-Init Nachrichten an alle CPUs gesendet und dann eine IPI-Startup Nachricht an alle und mit Hilfe eines Counters "zählt" man dann die CPUs. So stand es in einem Dokument von Intel.

ob das festpinnen oder IPIs oder irgendwas anderes ist ist ja erstmal egal

Stimmt, nur ist das Aufrufen des Schedulers nicht einfacher als den Algo des Schedulers irgendwie zu modifizieren?

Ich weiß es nicht genau aber das die Bulldozers Probleme mit dem geteilten Cache haben wird wohl eher am gegenseitigen Verdrängen durch Aliasing liegen, dieses Problem hatte Intel mit den ersten P4's mit Hyperthreading auch, da kann der Scheduler vom OS gar nix gegen tun (hier könnte höchstens besseres ASLR helfen), sowas muss in der HW gefixt werden.

Was genau meinst du mit "Aliasing"?

Soweit ich es vestanden habe, ist der Scheduler von Windows 7 sehr wohl ein Problem. Aus dem Grund warum Hyperthreading mit ihm besser funktioniert als vorher Denn der Scheduler arbeitet so, dass erst alle geraden Kerne (bei 0 startend) ausgelastet werden bis die ungeraden ausgelastet werden. Das soll die Effizienz bei Hyperthreading verbessern, aber da der L2-Cache bei einem "Dual"-Core beim Bulldozer immer gesharet wird, führt das zu Problem. Denn so werden immer genau die Kerne zu erst ausgelastet, die keinen gemeinsamen Cache haben.

Was mir daran ein wenig suspekt vorkommt, es scheint ja auf Mehrkern-CPUs ohne Hyperthreading auch zu funktionieren, dass alle Kerne ausgelastet werden. Also denke ich mal das AMD die ungeraden Kerne alle als Hyperthreading-Kerne (per CPUID) meldet und deswegen der Scheduler solche Entscheidungen trifft. Ist eigentlich ein Problem von AMD und nicht vom Windows-Scheduler. Ich finde es auch irgendwie behämmert, wenn man für jede CPU (und damit meine ich nicht mit oder ohne Hyperhtreading und Mehrkern CPUs) einen eigenen Scheduler braucht. Denn das Problem wäre ja durch eine einfache Änderung im CPUID-Befehl zu lösen.

Dafür wäre es interessant ob CPUID Mikrocode ist (wovon ich eigentlich ausgehe). Denn dann wäre es ja theoretisch möglich ein Update nachzuschieben.

Alles ist letztendlich (zumindest teilweise) subjektiv, und persönliche Meinungen erst recht.

Das stimmt wohl. Nur kann man sich z.B. nicht darüber streiten das 1+1 = 2 ist, oder

Das Problem mit KISS ist ja auch, eine Lösung ist nur solange KISS, bis eine noch einfachere gefunden wurde. Ist doch mit fast allen Sachen so, es ist so lange unmöglich bis jemand bewiesen hat das es möglich ist

[erik.vikinger]

Hallo,

Es wird eine (oder zwei) IPI-Init Nachrichten an alle CPUs gesendet und dann eine IPI-Startup Nachricht an alle und mit Hilfe eines Counters "zählt" man dann die CPUs. So stand es in einem Dokument von Intel.

Dazu müssen doch aber die anderen local-APIC bereits irgendwie konfiguriert sein damit diese die IPI's auch korrekt empfangen können, oder? Ich sehe da irgendwie eine Art von Henne-Ei-Problem. Wie bekommt man den eigentlich mit wie viele CPUs überhaupt vorhanden sind? Werden einfach alle möglichen durchprobiert und nur die die auch tatsächlich antworten gezählt?

Auf meiner Plattform soll das per Hardware gehen, ich habe einen CPU-Indentify-Ring-Bus vorgesehen, der beim Chipsatz anfängt und auch dort wieder aufhört. Der Chipsatz wartet bis alles aus dem Reset raus ist und triggert dann das Durchzählen der CPUs per Ring-Bus an, dabei werden die CPUs linear und auch physisch durchgezählt und der Chipsatz erhält dann am Ende das Ergebnis und weiß wie viele CPUs es insgesamt gibt und wie viele Sockel es insgesamt gibt. Erst danach weckt der Chipsatz automatisch die CPU 0 (indem er einfach in deren lokalen Controll-Registern eine Start-Adresse reinschreibt an der diese CPU dann anfängt den ersten Befehl zu holen). Damit das Zugreifen auf fremde Controll-Register überhaupt funktioniert ist es ja auch erforderlich das jede CPU weiß welche sie ist, sonst könnten diese Zugriffe ja nicht korrekt geroutet werden.

nur ist das Aufrufen des Schedulers nicht einfacher als den Algo des Schedulers irgendwie zu modifizieren?

Also ein simpler Funktionsaufruf ist IMHO schon einfacher als das Verschicken und vor allem Empfangen von IPI's oder gar als das Entwickeln eines komplexen mehrstufigen Schedulers.

Was genau meinst du mit "Aliasing"?

Das Problem damals bei den P4's mit Hyperthreading war das diese beiden logischen CPUs sich ja den einen physischen L1-Cache (Code und Daten) geteilt haben und das wenn z.B. verschiedene Programme auf die selbe libc zugreifen ist ja die Wahrscheinlichkeit hoch das diese libc in beiden Programmen an der selben virtuellen Adresse liegt und damit sich diese Zugriffe ständig gegenseitig aus dem L1-Cache verdrängen. Ein anderes Problemszenario war wenn mehrere Threads vom selben Prozess die selbe Aufgabe erledigen (z.B. in einem Grafik-Renderer) das dann u.a. die Stackzugriffe ein sehr ähnliches Zugriffsmuster haben und damit in den selben Cache-Lines gelandet sind so das hier auch wieder permanente gegenseitige Verdrängung vorherrschte. Nach Ende des P4-Experiments gab es ja ne Weile lang keine Hyperthreading-CPUs mehr von Intel und bei den Core-CPUs hat Intel, soweit ich das verstanden habe, das L1-Cache-Indexierungssystem für die beiden logischen CPUs unterschiedlich gemacht.

.... Denn so werden immer genau die Kerne zu erst ausgelastet, die keinen gemeinsamen Cache haben.

Okay, das ist ein anderes Problem, aber auch irgendwie doof. Vielleicht hätte AMD an Microsoft ein paar Vorabexemplare schicken sollen damit die mal schauen ob es irgendwo Probleme gibt, eventuell wäre den MS-Leuten sowas noch rechtzeitig aufgefallen.

Was ich mich frage ist wie das mit dem Energiesparen zusammen arbeitet. Wenn wir eine 4-Kern-CPU mit Hyperthreading und 3 mäßig gierige Threads haben würde der MS-Scheduler ja 3 Kerne unter Dampf setzen obwohl eigentlich 2 reichen könnten (die dafür eventuell sogar mit einem minimal höherem Takt laufen). Wenn diese Threads dann auch noch wenig effizienten oder nur wenig anspruchsvollen Code ausführen (so dass das Hyperthreading gar keine Bremse wäre) ist der MS-Scheduler ja eine echte Energieverschwendung.

eine Lösung ist nur solange KISS, bis eine noch einfachere gefunden wurde

Ja, deswegen kann ich ja auch ruhigen Gewissens behaupten das meine Segmente mehr KISS sind als Flat-Memory.


Grüße
Erik

[FlashBurn]

Dazu müssen doch aber die anderen local-APIC bereits irgendwie konfiguriert sein damit diese die IPI's auch korrekt empfangen können, oder? Ich sehe da irgendwie eine Art von Henne-Ei-Problem. Wie bekommt man den eigentlich mit wie viele CPUs überhaupt vorhanden sind? Werden einfach alle möglichen durchprobiert und nur die die auch tatsächlich antworten gezählt?

Du sollst, laut Intel, die IPI-Init Nachricht an alle und die IPI-Startup Nachricht nur an die CPUs schicken, von denen dir gesagt wurde das sie Ok sind (z.B. ACPI). Das BIOS schickt einfach die IPI-Startup Nachricht an alle CPUs (und ich vermute mal, wartet dann ne gewisse Zeitspanne) und die CPUs "registrieren" sich mit ihrer APIC-ID und das BIOS weiß dann wie viele CPUs es gibt.

Also ein simpler Funktionsaufruf ist IMHO schon einfacher als das Verschicken und vor allem Empfangen von IPI's

Dem kann ich nur zustimmen, das Senden ist ja noch einfach, aber das Empfangen bzw. vernünftige Abarbeiten von IPI´s ist nicht mehr so einfach.

Das Problem damals bei den P4's mit Hyperthreading war das diese beiden logischen CPUs sich ja den einen physischen L1-Cache (Code und Daten) geteilt haben und das wenn z.B. verschiedene Programme auf die selbe libc zugreifen ist ja die Wahrscheinlichkeit hoch das diese libc in beiden Programmen an der selben virtuellen Adresse liegt und damit sich diese Zugriffe ständig gegenseitig aus dem L1-Cache verdrängen. Ein anderes Problemszenario war wenn mehrere Threads vom selben Prozess die selbe Aufgabe erledigen (z.B. in einem Grafik-Renderer) das dann u.a. die Stackzugriffe ein sehr ähnliches Zugriffsmuster haben und damit in den selben Cache-Lines gelandet sind so das hier auch wieder permanente gegenseitige Verdrängung vorherrschte. Nach Ende des P4-Experiments gab es ja ne Weile lang keine Hyperthreading-CPUs mehr von Intel und bei den Core-CPUs hat Intel, soweit ich das verstanden habe, das L1-Cache-Indexierungssystem für die beiden logischen CPUs unterschiedlich gemacht.

Interessant zu wissen!

Okay, das ist ein anderes Problem, aber auch irgendwie doof. Vielleicht hätte AMD an Microsoft ein paar Vorabexemplare schicken sollen damit die mal schauen ob es irgendwo Probleme gibt, eventuell wäre den MS-Leuten sowas noch rechtzeitig aufgefallen.

Ich habe keine Ahnung seit wann AMD an Bulldozer entwickelt, aber ich denke mal der Windows 7 Scheduler war wohl zeitiger fertig und MS hat halt für Hyperthreading optimiert (und das war schon einige Zeit bevor Windows 7 erschienen ist, bekannt).

Was ich mich frage ist wie das mit dem Energiesparen zusammen arbeitet. Wenn wir eine 4-Kern-CPU mit Hyperthreading und 3 mäßig gierige Threads haben würde der MS-Scheduler ja 3 Kerne unter Dampf setzen obwohl eigentlich 2 reichen könnten (die dafür eventuell sogar mit einem minimal höherem Takt laufen). Wenn diese Threads dann auch noch wenig effizienten oder nur wenig anspruchsvollen Code ausführen (so dass das Hyperthreading gar keine Bremse wäre) ist der MS-Scheduler ja eine echte Energieverschwendung.

Ich weiß es natürlich nicht genau, aber es muss schon ne bestimmte Auslastung vorhanden sein bevor die logischen Core´s genutzt werden (das sehe ich immer sehr gut auf meinem Laptop). Ich denke also mal MS wird das schon halbwegs bedacht haben.

Ja, deswegen kann ich ja auch ruhigen Gewissens behaupten das meine Segmente mehr KISS sind als Flat-Memory.

Ich glaube da werden dir wohl fast alle wiedersprechen

[Svenska]

Ich weiß ja, dass du ein großer Fan von optimalen, überall perfekten Vollautomatismen und wunderbaren algorithmischen Lösungen bist, da brauchst du mir nicht die KISS-Definition herzitieren. Dennoch halte ich es für sinnvoll, den Automatismus abschaltbar machen zu können (oder ihn in ein bestimmtes Verhalten zwingen zu können).

Ein Autopilot in einem Flugzeug ist immer abschaltbar. Auch große Industrieanlagen kann man in der Regel manuell fahren (meist mit reduzierter Leistung). Und auch ein Not-Aus-Knopf an der Wand ist eine Implementation einer manuell abschaltbaren Automatik.

Du gehst im übrigen immer von "der Lösung" aus. Die gibt es nicht. Es gibt i.A. mehrere Ansätze, die zum Ziel führen, wobei jeder Ansatz Vor- und Nachteile hat. Universallösungen sind in der Regel over-engineered, funktionieren nur mäßig gut oder sind tierisch komplex.

[kevin]

Ja, meine Zeitscheiben sollen auch mehrere ms lang sein (ich dachte so an 10 ms bis etwa 20 ms) und, ja, das ist keine harte Echtzeit mehr.

Hm? Du kannst Zeitscheiben von 10 bis 20 Minuten nehmen und immer noch harte Echtzeit haben. Ob das nützlich ist, wäre natürlich noch die andere Frage, aber wenn du einen Reaktionszeit von zwei Tagen garantierst und das immer einhalten kannst, ist es harte Echtzeit.

Das festpinnen mag sicher gut funktionieren aber ich bin mir nicht sicher ob es auch Möglichkeiten gibt alle anderen Thread von dieser CPU zu verbannen. Dabei entstehen IMHO einige Probleme. Was ist wenn dieser eine Thread gerade blockiert? Bleibt die CPU dann unbenutzt? Geht die dann in einen Stromsparzustand (was eventuell längere Aufwachzeiten und damit Latenzen verursacht)? Wie viele CPUs in einem System kann man den ruhigen Gewissens frei räumen? Ich persönlich würde maximal die Hälfte zulassen und das auch nur wenn mindestens 4 CPUs verfügbar sind.

Da landen wir bei Mechanism und Policy. Der Kernel sollte nur den Mechanismus anbieten, aber nicht die Policy vorschreiben. Du hast vielleicht ganz andere Einschränkungen für deinen Einsatzzweck im Sinn als FlashBurn für seinen. Ob du jetzt den Ablauf durch einen (ersetzbaren) Userspaceteil abhandelst oder nur ein paar Stellschrauben für den Scheduler einplanst, ist deine Designentscheidung, aber ein paar Konstanten fest zu verdrahten, die dir gerade gut reinlaufen, ist mit Sicherheit falsch.

[FlashBurn]

Ich weiß ja, dass du ein großer Fan von optimalen, überall perfekten Vollautomatismen und wunderbaren algorithmischen Lösungen bist, da brauchst du mir nicht die KISS-Definition herzitieren. Dennoch halte ich es für sinnvoll, den Automatismus abschaltbar machen zu können (oder ihn in ein bestimmtes Verhalten zwingen zu können).

Mir ist bewusst, dass es nicht den perfekten Algo gibt und ich finde Linux ist der beste Beweis dafür Zumal du mir ja immer mit KISS kommst.

Nur ist das mit dem Festpinnen nicht so einfach umzusetzen, aber wie gesagt, das ist eigentlich Stoff für ein anderes Thema.

Ein Autopilot in einem Flugzeug ist immer abschaltbar. Auch große Industrieanlagen kann man in der Regel manuell fahren (meist mit reduzierter Leistung). Und auch ein Not-Aus-Knopf an der Wand ist eine Implementation einer manuell abschaltbaren Automatik.

Willst du mir damit sagen, dass man den Scheduler abschalten können sollte? Das ganze muss wieder mit einer Rechteverwaltung gelöst werden, wo ich noch keine richtige gute Idee habe.

[Svenska]

Dennoch halte ich es für sinnvoll, den Automatismus abschaltbar machen zu können (oder ihn in ein bestimmtes Verhalten zwingen zu können).

Der Teil in Klammern ist wichtig. Den Scheduler komplett abzuschalten ist eher nicht sinnvoll.

Festpinnen heißt übrigens nicht nur, dass ein Thread ausschließlich auf einer CPU ausgeführt werden darf, sondern auch, dass ein Thread auf einer bestimmten CPU nicht ausgeführt werden darf. Also eine Festlegung pro Thread, welche CPUs zulässig sind.

[FlashBurn]

Festpinnen heißt übrigens nicht nur, dass ein Thread ausschließlich auf einer CPU ausgeführt werden darf, sondern auch, dass ein Thread auf einer bestimmten CPU nicht ausgeführt werden darf. Also eine Festlegung pro Thread, welche CPUs zulässig sind.

Und du willst immernoch behaupten, dass das Festpinnen den Scheduler einfacher macht

Für gewöhnlich (also rede ich von Windows ) darf das Programm doch nicht selbst entscheiden, ob es nur auf einer bestimmten CPU läuft (??). Der User muss das also machen, aber ich wüsste nicht dass man das für jeden Thread extra festlegen könnte, sondern immer nur für ganze Prozesse und damit macht es eh nur Sinn für Singel-Threaded Anwendungen. Gut man könnte den Scheduler jetzt zwingen jeden Thread auf einer extra CPU laufen zu lassen. Ich kann mir nur einfach nicht vorstellen, dass das bei Multithreading sinnvoll ist.

[Svenska]

Dann lässt du es halt sein. Ich klinke mich an der Stelle aus.

[kevin]

Von Windows habe ich keine Ahnung aber sched_setaffinity(2) unter Linux braucht wohl keine speziellen Berechtigungen, wenn man sich selbst pinnen will. Und man kann natürlich auch einzelne Threads pinnen, wenn man das will.

[FlashBurn]

Von Windows habe ich keine Ahnung aber sched_setaffinity(2) unter Linux braucht wohl keine speziellen Berechtigungen, wenn man sich selbst pinnen will. Und man kann natürlich auch einzelne Threads pinnen, wenn man das will.

Naja, bei sich selbst sollte das auch kein Problem darstellen, aber kann man auch Threads anderer Prozesse pinnen? Und ist es unter Linux so wie svenska meinte, dass man auch sagen kann auf welchen CPUs der Thread nicht laufen darf?

Was ich unter Windows meinte, ist die Sache die man im Taskmanager festlegen kann, wie das im Programmcode funktioniert weiß ich auch nicht.

[kevin]

Ich hab dir doch extra den Funktionsnamen gepostet, damit du die Manpage selber nachlesen kannst. Aber bitteschön, ich kann die entscheidende Passage auch für dich kopieren: "The caller needs an effective user ID equal to the real user ID or effective user ID of the process identified by pid, or it must possess the CAP_SYS_NICE capability."

Und wenn man festlegen kann, auf welchen CPUs der Thread laufen darf, dann legt man damit logischerweise auch unvermeidlich fest, auf welchen CPUs er nicht laufen darf.

[FlashBurn]

Ich hab dir doch extra den Funktionsnamen gepostet, damit du die Manpage selber nachlesen kannst.

Es ist Freitag

Und wenn man festlegen kann, auf welchen CPUs der Thread laufen darf, dann legt man damit logischerweise auch unvermeidlich fest, auf welchen CPUs er nicht laufen darf.

Ich dachte man kann nur festlegen auf welcher CPU und nicht CPUs der Thread laufen darf. Am Bsp. des Bulldozers, würde es ja Sinn machen immer 2 Kerne anzugeben, wo ein Thread drauf laufen darf.

[kevin]

Mensch, klick doch endlich auf den Link und schau dir die Manpage an.

sched_setaffinity() nimmt einen cpu_set_t*, nicht eine einzelne CPU-Nummer.

[FlashBurn]

Mensch, klick doch endlich auf den Link und schau dir die Manpage an.

sched_setaffinity() nimmt einen cpu_set_t*, nicht eine einzelne CPU-Nummer.

Hab ich doch schon längst gemacht, deswegen habe ich ja auch in einer Vergangenheitsform geschrieben

[erik.vikinger]

Hallo,

Das BIOS schickt einfach die IPI-Startup Nachricht an alle CPUs (und ich vermute mal, wartet dann ne gewisse Zeitspanne) und die CPUs "registrieren" sich mit ihrer APIC-ID und das BIOS weiß dann wie viele CPUs es gibt.

Ich kann mich irren aber ich vermute das wird nicht reichen, bei modernen CPUs wo der Speicher selber auch an der CPU hängt muss das BIOS schon etwas konkreter über die physische Verschaltung und auch den Funktionsumfang der beteiligten CPUs informiert sein damit es z.B. auch das Routing von Speicherzugriffen innerhalb des CPU-Netzwerkes korrekt konfigurieren kann (das ist auch deswegen erforderlich weil ja nicht jeder Sockel mit jedem anderen Sockel verbunden ist so das mache Anfragen eben mehrere Hops benötigen).

Ja, deswegen kann ich ja auch ruhigen Gewissens behaupten das meine Segmente mehr KISS sind als Flat-Memory.

Ich glaube da werden dir wohl fast alle wiedersprechen

Nur zu, wenn ich mal soweit bin das ich meinen Standpunkt auch ordentlich beweisen kann dürfte der Widerspruch verstummen.

Und auch ein Not-Aus-Knopf an der Wand ist eine Implementation einer manuell abschaltbaren Automatik.

Hm, wo wohnst Du denn das bei Dir an den Wänden ein Not-Aus-Knopf ist? Bitte erzähle jetzt nicht das die Wände bei Dir nicht nur mit einem Not-Aus-Knopf sondern auch mit flauschig weicher Polsterung ausgestattet sind. SCNR

Universallösungen sind in der Regel over-engineered, funktionieren nur mäßig gut oder sind tierisch komplex.

Oder alles zusammen.

aber wenn du einen Reaktionszeit von zwei Tagen garantierst und das immer einhalten kannst, ist es harte Echtzeit.

Ja, ich weiß, soviel zur Theorie. Ich dachte aber eigentlich immer das Du eher der praktisch denkende Mensch wärst.

aber ein paar Konstanten fest zu verdrahten, die dir gerade gut reinlaufen, ist mit Sicherheit falsch.

Ich nehme mal an das Du damit meinst das ich nur maximal die Hälfte der CPUs für die exklusive Nutzung eines einzelnen Threads reservieren würde. Natürlich ist das eine willkürliche Festlegung die mir so einfach in den Kram passt, trotzdem steckt da aber auch ein praktischer Gedanke dahinter, ich will ja mein System nicht tot machen (in dem Punkte sollte noch nicht einmal root das Recht haben sein System an die Wand zu hauen). Der nächste Aspekt ist der das sich die anderen Programme ja auch implizit auf eine Policy verlassen und das darf ein General-Purpose-OS eben auch nicht ganz vergessen. Aber das ist alles natürlich nur meine persönliche Meinung die auch nicht für jeden Anwendungsfall zutreffend sein muss.


Ob ich in mein OS jemals einen Mechanismus zum festpinnen implementiere würde ich aus heutiger Sicht eher bezweifeln, das kann in Zukunft natürlich auch anders werden. Über den Sinn oder Unsinn dieses Mechanismus will ich auch gar nicht streiten (das ist IMHO völlig aussichtslos) aber über die praktische Realisierung würde ich schon ganz gerne mal diskutieren.


Grüße
Erik

[kevin]

Ja, ich weiß, soviel zur Theorie. Ich dachte aber eigentlich immer das Du eher der praktisch denkende Mensch wärst.

Aber auch jemand, der auf saubere Terminologie Wert legt.

Wenn du meine praktische Meinung zum Thema wissen willst: In meinem Hobby-OS brauche ich keine harte Echtzeit.

Natürlich ist das eine willkürliche Festlegung die mir so einfach in den Kram passt, trotzdem steckt da aber auch ein praktischer Gedanke dahinter, ich will ja mein System nicht tot machen (in dem Punkte sollte noch nicht einmal root das Recht haben sein System an die Wand zu hauen). Der nächste Aspekt ist der das sich die anderen Programme ja auch implizit auf eine Policy verlassen und das darf ein General-Purpose-OS eben auch nicht ganz vergessen. Aber das ist alles natürlich nur meine persönliche Meinung die auch nicht für jeden Anwendungsfall zutreffend sein muss.

Es spricht ja nichts dagegen, gute Defaults zu haben, und solange es nur Defaults sind, kannst du sie auch mehr oder weniger beliebig so wählen, wie du es gerade für richtig hältst. Aber ein paar willkürliche Zahlen fest zu verdrahten ist einfach falsch.

[erik.vikinger]

Hallo,

In meinem Hobby-OS brauche ich keine harte Echtzeit.

Das sehe ich für mein Projekt ganz genau so, trotzdem hätte ich z.B. gerne das normale Audio/Video-Programme ohne knacksen und ruckeln arbeiten können, das war es doch schließlich was FlashBurn an Windows gestört hat. Das Problem ist wenn man Latenzen zusichern möchte die kürzer als eine Zeitscheibe (plus ein wenig Reserve) sind dann muss man den Scheduler schon mit ein paar Tricks extra ausstatten, ob dass das Festpinnen von Threads ist oder gar das Freiräumen von einzelnen CPUs für einen einzigen Thread oder auch was ganz anderes ist dann wieder ein Implementierungsdetail und hängt auch davon ab wie das Ergebnis konkret aussehen soll. Das Freiräumen einer CPU zur exklusiven Nutzung durch einen einzigen Thread ist IMHO durchaus eine gute Option weil somit gewährleistet ist das dieser Thread immer sofort seine CPU haben kann (nebst dessen das ihm niemand seinen Cache-Inhalt trasht) aber das ist auch eine extrem teure Lösung weil man ja üblicherweise nur ein paar wenige CPUs zur Verfügung hat so dass das restliche System durch den Wegfall von ganzen CPUs durchaus erheblich beeinträchtigt wird (nebst dessen dass das Freiräumen von CPU wegen der erheblichen Einbußen für das restliche System auch nur mit besonderen Rechten passieren darf). Das bloße Festpinnen einzelner Threads oder Prozesse auf bestimmte CPUs bringt im Punkt Latenz IMHO eher wenig, auf einem normalen System dürfte es immer noch genügend andere Threads geben die auch mal auf einer der zugeordneten CPUs laufen und damit eben trotzdem im Weg sein können. Das Festpinnen bringt eher ein klein wenig für die Performance, z.B. wenn ein Prozess genau so viele Workerthreads startet wie CPUs vorhanden sind und diese unterschiedliche Datensätze verarbeiten kann es von Vorteil sein das jeder dieser Workerthreads immer nur auf einer CPU laufen kann und so das kostspielige hin und her transferieren von Cache-Inhalten entfallen kann, solange das restliche System alle CPUs ungefähr gleichmäßig zusätzlich beansprucht dürften die Workerthreads davon tatsächlich profitieren wenn aber z.B. die HW-IRQs immer nur von einer CPU bearbeitet werden dann wäre der Workerthread der auf dieser CPU läuft erheblich benachteiligt.

Aber ein paar willkürliche Zahlen fest zu verdrahten ist einfach falsch.

Es gibt in einem normalen OS sicher unzählige solcher Defaults und etliche davon kann man auch verändern aber wie viele Prozent der normalen User tun das? Auf wie vielen Linux-Systemen darf ein normaler User mehr als 95%-Plattenplatz belegen (per Default werden doch 5% für root reserviert, was auf einer aktuellen Multi-TB-Platte schon einiges ist) obwohl dieses Default relativ einfach zu ändern ist. Natürlich ist selbst das kein Grund so ein Default einfach im Datei-System-Treiber oder gar im VFS fest zu verdrahten aber es macht IMHO durchaus Sinn für solche Stellschrauben Grenzen festzulegen. Wenn ich definiere das z.B. mindestens 2 CPUs oder mindestens 10% aller CPUs (also das was größer ist) nicht zur exklusiven Zuweisung an einzelne Threads benutzt werden dürfen dann mag das zwar willkürlich erscheinen kann aber einfach auch eine untere Grenze sein die mein OS benötigt um sauber laufen zu können und die noch nicht mal root verletzen darf. Stellschrauben können immer auch negative Effekte haben und ich denke ein guter Programmierer sollte sich bemühen sinnvolle Grenzen festzulegen, wobei sinnvoll eben bedeutet das zum einen die Stellschraube auch was nützt aber trotzdem wenigstens der gröbste Schaden verhindert wird.


Grüße
Erik