Thema: Threads blockieren und wieder aufwecken

[FlashBurn]

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.

Problem unter Windows sind schlechte Treiber und die Architektur des Kernels. Während bestimmte Teile von Treibern abgehandelt werden (das DPC Zeugs), sind die Ints aus und jeder Treiber sollte nicht viel machen (als wenn das so klappt, da bin ich z.B. dafür das man dazu gezwungen wird), da es ansonsten zu dem geschilderten Problemen kommt.

Ich möchte das ja so lösen, das Treiber in Form von Real-Time-Threads laufen (die bekommen immer die CPU, allerdings auch in Round-Robin Manier, wenn es genug gibt). So ist es auf jeden Fall nicht möglich das ein Thread/Treiber das ganze System unbenutzbar macht (es geht nix mehr, auch kein Maus/Tastatur).

Wegen dem Cache-Trashing dachte ich daran, in jeder Thread-Struktur die ID der CPU zu speichern, auf der der Thread zu letzt gelaufen ist und wenn die Liste der Ready-Threads (allerdings immer nur pro Priorität) durchgegangen wird, wird vorzugsweise ein Thread genommen, der als letztes genau auf der CPU gelaufen ist. Um das ganze nicht alzu lang (aber auch das ist relativ) werden zu lassen, wollte ich festlegen, dass max "Anzahl vorhandener CPUs" Threads angefasst werden und dann einer genommen wird.

[kevin]

Klar, das Festpinnen bringt nur in einigen bestimmten Fällen was. Wenn du nur verhindern willst, dass die Musik Aussetzer hat, dann bringt dir das gar nichts. An dieser Stelle würde ich dir stattdessen einfach empfehlen, den Soundtreiber so zu schreiben, dass er anders als Windows Puffer benutzt, die länger als ein paar Millisekunden sind... Das merkt man auch in VMs recht deutlich: Mit Windows-Gästen gibt es immer wieder Aussetzer, Linux benutzt größere Puffer und tut problemlos, auch wenn es nicht die ganze physische CPU für sich hat. (Hängt natürlich vermutlich vom konkreten Treiber ab, aber bei intel-hda ist es so und das hat ja schon ein gewisse Verbreitung)

[FlashBurn]

An dieser Stelle würde ich dir stattdessen einfach empfehlen, den Soundtreiber so zu schreiben, dass er anders als Windows Puffer benutzt, die länger als ein paar Millisekunden sind... Das merkt man auch in VMs recht deutlich: Mit Windows-Gästen gibt es immer wieder Aussetzer, Linux benutzt größere Puffer und tut problemlos, auch wenn es nicht die ganze physische CPU für sich hat. (Hängt natürlich vermutlich vom konkreten Treiber ab, aber bei intel-hda ist es so und das hat ja schon ein gewisse Verbreitung)

Da wären wir wieder bei Workaround

Ich finde es kann nicht sein, das man größere Puffer braucht, immerhin reden wir hier von einem QuadCore@3.2GHz. Zumal ich ja weiß das es unter Windows funktioniert (nur halt nicht unter Win7 x64).

[kevin]

Das hat nichts mit Workaround zu tun. Winzige Puffer sind immer langsam, ob das jetzt Sound, Netzwerk oder Festplatte ist. Wenn überhaupt, dann ist ein Scheduler, der darauf optimiert ist, dass solche CPU-fressenden Treiber trotzdem einigermaßen laufen, ein Workaround.

[erik.vikinger]

Hallo,

Während bestimmte Teile von Treibern abgehandelt werden (das DPC Zeugs), sind die Ints aus und jeder Treiber sollte nicht viel machen (als wenn das so klappt, da bin ich z.B. dafür das man dazu gezwungen wird), da es ansonsten zu dem geschilderten Problemen kommt.

Also Dein Satzbau ist mal wieder, äh, kreativ. Ich versuche einfach mal so gut es geht zu interpretieren. Der Vorteil an den DPCs von Windows ist ja gerade das dabei die INTs an sind, die DPCs sind nämlich die zweite Ebene bei der IRQ-Verarbeitung. Ich bin mir ziemlich sicher dass das zumindest bis einschließlich Windows XP noch genau so war, denn dafür hab ich schon mal Treiber programmiert. Das Erzwingen von möglichst kurzen IRQ-Handlern (erste Ebene) stelle ich mir schwierig bis unmöglich vor, ich glaube auch nicht dass das wirklich was bringen würde (die Treiber-Programmierer sind sicher kreativ genug um da irgendwie drumrum zu kommen, hier wäre IMHO eine strengere Qualitätskontrolle bei der Treiber-Zertifizierung zielführend, aber das will MS ja gar nicht weil man damit die ganzen Billig-HW-Anbieter aus dem Markt drängen würde und die im schlimmsten Falle noch anfangen Linux-Treiber für ihre HW zu schreiben).

Ich möchte das ja so lösen, das Treiber in Form von Real-Time-Threads laufen (die bekommen immer die CPU

Alle Treiber? Auch z.B. für einen USB-Ethernet-Controller? Wie ist das generell für USB-Devices oder Dateisystem-Treiber (diese Treiber haben ja eigentlich keinen eigenen HW-Zugriff und daher auch keine IRQ-Handler)? Werden Real-Time-Threads von Deinem Scheduler immer bevorzugt? Was im Endeffekt auch nur eine höhere Priorität darstellt. Wenn alle Treiber die selbe (Real-Time-)Priorität haben kann es eben doch wieder passieren das (schlechte) Treiber für unwichtige Hardware das System blockiert oder zumindest stärker belastet als der User will. Ich würde eher vorschlagen das Du bei Deinem IPC-System vorsiehst das die Priorität des Caller an den Callee vererbt werden kann (nicht muss). Damit könnte z.B. ein wichtiger Prozess, der vom User eine hohe Priorität bekommen hat, auch seine I/O-Aktivitäten mit hoher Priorität laufen lassen. Damit wäre es auch egal ob das Video-Programm von einer SATA-HDD oder von einer USB-HDD streamt, das System würde diesen Stream auf jeden Fall mit hoher Priorität behandeln so dass das Programm die gegebene Hardware zu gut wie möglich ausschöpfen kann und zwar egal wie viele andere niedriger priorisierte Programme auch noch an die selbe HDD wollen oder anderweitig Last verursachen.

So ist es auf jeden Fall nicht möglich das ein Thread/Treiber das ganze System unbenutzbar macht (es geht nix mehr, auch kein Maus/Tastatur).

Ich würde sagen das wenn Du jedem beliebigen Treiber Real-Time-Priorität gibst es erst recht möglich ist das weder Maus noch Tastatur gehen.

Wegen dem Cache-Trashing dachte ich daran ....

Hm, die Idee gefällt mir irgendwie. Ich habe zwar das ungute Bauchgefühl das dadurch der Scheduler teurer wird aber der erhoffte Vorteil nur zu selten wieder rein kommt (die meisten Programme sind nicht so stark Cache-Abhängig). Ist aber auf jeden Fall mal eine genauere Betrachtung wert, kommt gleich in meine ToDo-Liste, Danke.

Klar, das Festpinnen bringt nur in einigen bestimmten Fällen was. Wenn du nur verhindern willst, dass die Musik Aussetzer hat, dann bringt dir das gar nichts.

Es könnte was bringen wenn man dem Audio-Thread eine CPU exklusiv zuweist aber das bedeutet eben das man alle anderen Threads auf die verbleibenden CPUs festpinnen muss was ganz klar wieder ein Problem mit der Rechteverwaltung bringt und auch nur für eine sehr begrenze Anzahl an wichtigen Threads machbar ist (ich denke hier muss in jedem Fall eine vernünftige Reserve an frei verfügbaren CPUs für das restliche System übrig bleiben).

An dieser Stelle würde ich dir stattdessen einfach empfehlen, den Soundtreiber so zu schreiben, dass er anders als Windows Puffer benutzt, die länger als ein paar Millisekunden sind...

Gerade das will man aber im (semi-)professionellen Umfeld bei der Audio/Video-Produktion nicht. Da möchte man z.B. das der SW-Synthesizer mit möglichst kurzer Latenz auf die Tastatur reagiert (damit der Musiker einigermaßen in Echtzeit spielen kann) und benutzt deswegen möglichst kurze Puffer. Hierfür würde es eben helfen wenn der Scheduler bei jeder Änderung an der Anzahl oder den Prioritäten der lauffähigen Threads eine neue optimale Verteilung dieser Threads auf die CPUs vornimmt, damit könnte man recht zuverlässig verhindern das ein Thread mit hoher Priorität (bis zu) eine ganze Zeitscheibe lang warten muss bis der Thread mit niedriger Priorität endlich vom Scheduler unterbrochen wird damit der Thread mit der hohen Priorität laufen kann. Klar kostet sowas permanent etwas zusätzliche CPU-Leistung (der Scheduler wird teurer) aber im Fall eines "QuadCore@3.2GHz" kann ich natürlich verstehen das FlashBurn (völlig zu recht) sich über das OS ärgert weil er diese CPU-Leistung gerne investieren würde um dafür eine flüssige Wiedergabe zu haben.


Grüße
Erik

[FlashBurn]

Der Vorteil an den DPCs von Windows ist ja gerade das dabei die INTs an sind, die DPCs sind nämlich die zweite Ebene bei der IRQ-Verarbeitung. Ich bin mir ziemlich sicher dass das zumindest bis einschließlich Windows XP noch genau so war, denn dafür hab ich schon mal Treiber programmiert.

Ich dachte das die INTs da aus sind und deswegen schlechte Treiber zu Problemen führen.

Alle Treiber?

Hmm, also zumindest die IRQ-Handler (die ja als Popup-Thread gestartet werden).

Wie ist das generell für USB-Devices oder Dateisystem-Treiber (diese Treiber haben ja eigentlich keinen eigenen HW-Zugriff und daher auch keine IRQ-Handler)?

Da würde ich entweder den Aufrufer (Callee bekommt selbe Priorität wie Caller) "entscheiden" lassen oder halt den Treiberprogrammierer nach der Latenz, die benötigt wird.

Ich würde sagen das wenn Du jedem beliebigen Treiber Real-Time-Priorität gibst es erst recht möglich ist das weder Maus noch Tastatur gehen.

Der Punkt ist, dass die INTs an sind und so IRQs noch ankommen und die Real-Time-Priorität auch "nur" eine gewisse Zeitscheibe bekommt (da bin ich mir noch nicht sicher wie groß die sein sollte) und ansonsten ja Round-Robin greift, so dass zumindest jeder Treiber mal dran kommt.
Das ist ja gerade der Vorteil, das ein Treiber nicht das ganze System außer gefecht setzen kann.

Ich habe zwar das ungute Bauchgefühl das dadurch der Scheduler teurer wird aber der erhoffte Vorteil nur zu selten wieder rein kommt (die meisten Programme sind nicht so stark Cache-Abhängig).

Das Problem an der Lösung ist, dass der Scheduler desto teurer wird, desto mehr CPUs man hat (er also in dem Fall O(n) wird, wo meiner bisher O(1) ist). Allerdings wird das bei mir nicht so schlimm werden, da ich eh mehrere Scheduler habe (im Moment 2) und zur Bootzeit, je nach CPU Anzahl, entschieden wird welcher genommen wird. Dadurch kann ich ab einer gewissen Zahl von CPUs ein ganz anderes Konzept für den Scheduler wählen.

Man muss bei diesem Problem auch ganz deutlich zw Server (Mehrsockel-Systeme) und normalem PC unterscheiden. Ich will kein neues Server-OS entwickeln, sondern eher in die Richtung Multimedia-OS (auch wenn ich ein paar Sachen vorhabe, die man eher im Embedded- und Server-Bereich braucht). Da dürfte die Cache-Problematik sowieso nicht so schlimm sein (zumindest bei Intel CPUs).

Wie es z.B. auf ARM aussieht weiß ich gar nicht.

[kevin]

Es könnte was bringen wenn man dem Audio-Thread eine CPU exklusiv zuweist aber das bedeutet eben das man alle anderen Threads auf die verbleibenden CPUs festpinnen muss

Das ist aber dummerweise nicht so richtig praktikabel, solange wir beim durchschnittlichen Rechner bei 2 bis maximal 8 CPUs sind. Und du wolltest die Diskussion ja unter praktischen Gesichtspunkten führen.

Gerade das will man aber im (semi-)professionellen Umfeld bei der Audio/Video-Produktion nicht.

Moment, professionelles Umfeld - wenn davon bisher die Rede war, dann hab ich das verpasst.

Da möchte man z.B. das der SW-Synthesizer mit möglichst kurzer Latenz auf die Tastatur reagiert (damit der Musiker einigermaßen in Echtzeit spielen kann) und benutzt deswegen möglichst kurze Puffer.

Ich muss zugeben, dass ich die Hardware an dieser Stelle nicht gut genug kenne, aber ich bin mir relativ sicher, dass man einen angefangenen Puffer nicht zwingend zu Ende spielen muss. Ob es im allgemeinen ein definiertes Ergebnis gibt, wenn man den Puffer ändert, während die Hardware schon spielt oder man besser auf einen neuen Puffer wechselt, weiß ich nicht.

Auf jeden Fall gibt es nur dann einen Grund, keinen vollständigen langen Puffer zu spielen, wenn irgendein Ereignis eintritt. Für mich heißt das, dass man anstreben sollte, Kosten auch nur mit diesem Ereignis zu verbinden. Solange ich völlig unprofessionell nur ein bisschen Musik im Hintergrund hören will, sehe ich es nicht ein, warum das unnötig viel CPU-Zeit kosten sollte und dafür womöglich auch noch ein schlechteres Ergebnis bekomme, weil nicht schnell genug nachgeliefert wird.

[erik.vikinger]

Hallo,

Ich dachte das die INTs da aus sind und deswegen schlechte Treiber zu Problemen führen.

Nein, innerhalb der DPCs sind die INTs an aber die DPCs stellen wimre die höchste Priorität dar so das selbst Prozesse mit sehr hoher Priorität von unwichtiger HW (bzw. von deren schlechten Treibern) verdrängt werden können.

Hmm, also zumindest die IRQ-Handler (die ja als Popup-Thread gestartet werden).

Damit würdest Du aber alle IRQs auf eine einzige Prioritätsstuffe stellen und das ist IMHO nicht sehr geschickt. Die Priorität von HW-Geräten und deren IRQs sollte meiner Meinung nach von der Priorität der gerade erfüllten Aufgaben abhängen. Wenn Du z.B. Daten über die RS232-Schnittstelle übertragen willst dann sollte der IRQ-Handler und auch der IRQ für den UART genau eine Prioritätsstufe höher sein als die Anwendung die die Daten überträgt so das wenn daneben noch andere Anwendungen mit wesentlich höherer Priorität laufen diese nicht mal durch den IRQ bzw. IRQ-Handler der RS232-Schnittstelle verdrängt werden können. Kompliziert wird dieses Konzept eigentlich nur wenn ein HW-Gerät für verschiedene Anwendungen (mit unterschiedlicher Priorität) Aufgaben erfüllen muss. IRQ-Sharing steht diesem Konzept auch etwas im Wege.

Da würde ich entweder den Aufrufer (Callee bekommt selbe Priorität wie Caller) "entscheiden" lassen

Natürlich muss der Caller die Möglichkeit zum Entschieden haben.

oder halt den Treiberprogrammierer nach der Latenz, die benötigt wird.

Der Treiberprogrammierer weiß doch noch gar nicht welche Anforderungen später mal zur Laufzeit zu erfüllen sind. Siehe mein Beispiel oben mit der RS232-Schnittstelle oder auch beim Beispiel mit der Soundkarte macht es einen Unterschied ob man einfach nur im Hintergrund mit etwas MP3 berieselt werden will (hier spielt die Latenz gar keine Rolle weil der MP3-Player ja mehrere riesige Puffer im voraus berechnen kann) oder ob jemand am Computer ein SW-Instrument spielen möchte (hier sind möglichst kurze Latenzen sehr wichtig damit sich das Instrument gut spielen lässt aber dafür ist der Musiker sicher auch bereit keine andere CPU-intensive Anwendung parallel laufen zu lassen usw).

Der Punkt ist, dass die INTs an sind und so IRQs noch ankommen

Das heißt also das bei Dir die IRQ-Handler für wichtige HW-Geräte auch durch IRQs von weniger wichtigen HW-Geräten unterbrochen werden können? Also in meinem Konzept ist das konsequent ausgeschlossen, weil die Priorität des IRQs immer mit der Priorität des IRQ-Handler identisch ist (sichert der Kernel zu).

und die Real-Time-Priorität auch "nur" eine gewisse Zeitscheibe bekommt (da bin ich mir noch nicht sicher wie groß die sein sollte) und ansonsten ja Round-Robin greift, so dass zumindest jeder Treiber mal dran kommt.

Schon klar, weil alle IRQ-Handler gleich sind kommen alle auch irgendwie vorwärts. Die Frage ist aber: ist es das was Du wirklich willst? Wäre es nicht besser wenn die die wichtigen HW-Geräte eine höhere Priorität als die weniger wichtigen HW-Geräte haben? Und wäre es nicht praktisch wenn die Priorität der HW-Geräte sich dynamisch nach der Wichtigkeit der von ihnen momentan bearbeiteten Aufgaben richtet?
Was machst Du eigentlich wenn die gewünschte Latenz kleiner als die Zeitscheibe ist? Bei Round-Robin kann die Latenz auch mal das X-fache einer Zeitscheibe werden.

Das Problem an der Lösung ist, dass der Scheduler desto teurer wird, desto mehr CPUs man hat (er also in dem Fall O(n) wird, wo meiner bisher O(1) ist).

Ich würde eher sagen das der Scheduler dann O(n/2) o.ä. ist weil es ja doch recht wahrscheinlich ist das einer der nächsten Threads auf der gerade aktuellen CPU als letztes gelaufen ist, ich denke da an das Geburtstagsproblem (bin aber aber auch nicht so sicher dass das hier wirklich zutrifft).

Man muss bei diesem Problem auch ganz deutlich zw Server (Mehrsockel-Systeme) und normalem PC unterscheiden.

Stimmt, die Cache-Problematik sollte bei einem Single-Sockel-System gar nicht mal so schlimm werden da ja bei Intel und auch bei AMD die letzte Cache-Ebene immer für alle Cores gemeinsam gilt, kritisch werden wohl erst Mehr-Sockel-Systeme. Insofern könnte man den Scheduler oben auch soweit vereinfachen das er auch Threads nimmt die nur auf dem selben Core (bei Hyperthreading) oder auf dem selben Sockel gelaufen sind (je nach dem wo z.B. ein gemeinsamer L2-Cache vorhanden ist).

Die meisten ARM-MultiCore-SoCs haben üblicherweise pro Core einen kleinen L1-Daten-Cache und einen kleinen L1-Code-Cache aber zusätzlich noch einen großen und gemeinsamen L2-Cache für alles, von daher denke ich dass das Cache-Problem bei den heutigen ARM-MultiCore-SoCs nicht allzu bedeutend ist.

Das ist aber dummerweise nicht so richtig praktikabel

Ach ne, darauf will ich doch die ganze Zeit hinaus, diese Lösung hat zwar ihren Reitz ist aber einfach zu teuer. Wenn irgendwann einmal selbst der billigste ALDI-PC mindestens 16 echte Cores hat und das mitgelieferte OS aber auch mit 20% davon zufriedenstellend läuft dann ist diese Methode eine Überlegung wert (an der Erfüllung des zweiten Kriteriums wird aber MS erheblich dagegen arbeiten).

Moment, professionelles Umfeld - wenn davon bisher die Rede war, dann hab ich das verpasst.

Ob nun unbedingt professionell oder nicht ist erst mal egal aber es ging mir eindeutig nicht um nen MP3-Player für die Hintergrundberieselung.

aber ich bin mir relativ sicher, dass man einen angefangenen Puffer nicht zwingend zu Ende spielen muss.

Gewiss, aber wenn Du kein Knacksen haben willst musst Du aufs Sample genau wissen an welcher Stelle der Puffer abgebrochen wird und auch rechtzeitig einen neuen Puffer bereit stellen der stattdessen weitergespielt werden soll. Das erscheint mir recht aufwendig, da würde ich es bevorzugen einfach in einem festen Raster zu arbeiten, obwohl das dynamische auch einen interessanten Eindruck macht.

Ob es im allgemeinen ein definiertes Ergebnis gibt, wenn man den Puffer ändert, während die Hardware schon spielt oder man besser auf einen neuen Puffer wechselt, weiß ich nicht.

Einen einmal übergebenen Puffer zu ändern halte ich für eine ganz schlechte Idee weil Du nie genau weiß wie weit die HW diesen Puffer schon eingelesen hat (und die Daten in der HW puffert). Kontrolliert Wechseln ist da IMHO eher machbar aber eben mit dem potentiellen Problem des Knacksens.


Grüße
Erik

[FlashBurn]

Nein, innerhalb der DPCs sind die INTs an aber die DPCs stellen wimre die höchste Priorität dar so das selbst Prozesse mit sehr hoher Priorität von unwichtiger HW (bzw. von deren schlechten Treibern) verdrängt werden können.

Das macht das Problem für mich noch unverständlicher. Ich weiß das es unter WinXP definitiv nicht auftritt, bei Win7 x86 bin ich mir nicht sicher, aber ich bin mir sicher das es ein Treiber-Problem ist. Auf meinem Laptop wo auch Win7 x64 läuft, habe ich diese Probleme nicht. Diese Latency Probleme sind aber von Gerät zu Gerät unterschiedlich. Deswegen liegt es irgendwo am Konzept bzw. den Treibern (unter Linux scheint es die Probleme ja nicht zu geben).

Die Priorität von HW-Geräten und deren IRQs sollte meiner Meinung nach von der Priorität der gerade erfüllten Aufgaben abhängen.

Hmm, darüber müssen wir diskutieren

Also ich bin der Meinung alle IRQs sollten erstmal behandelt werden, damit es halbwegs schnell weitergehen kann. Allerdings habe ich bei mir auch die Möglichkeit die Priorität der IRQs festzulegen. Da würde es dann schon Sinn machen diese Priorität auch an die IRQ-Handler weiterzugeben.

Der Treiberprogrammierer weiß doch noch gar nicht welche Anforderungen später mal zur Laufzeit zu erfüllen sind.

Da bin ich halt anderer Meinung. Um mal dein Bsp. mit dem MP3-Player, der im Hintergrund läuft, aufzugreifen. Ich möchte eigentlich auch da das es zu keinen Aussetzern kommt, dann läuft halt z.B. die Kompilierung langsamer, aber die Musik läuft durchgehend. Das meine ich mit Latenz und das der Treiberprogrammierer die kennen sollte.
An diesem Bsp. sieht man halt gut, worauf jeder Wert legt. Mir ist es wichtig das die Daten dann zum entsprechenden Zeitpunkt in die Hardware kommen, auch wenn dafür ein Prozess mit höherer Priorität (ausgehend von einem MP3-Player im Hintergrund und einer Kompilierung um Vordergrund) verdrängt wird.

Ich muss aber zugeben, dass ich absolut keine Ahnung habe wie das genau mit den Treibern (am Bsp von Soundkarten) genau funktioniert. Sprich ob man z.B. wie du es immer meinst, einfach nen riesigen Buffer an den Treiber übergeben kann oder nicht.

Um es nochmal deutlich zu sagen, es geht mir dabei um den Treiber, nicht um das Programm welches die Daten für den Treiber erzeugt.

Die Frage ist aber: ist es das was Du wirklich willst? Wäre es nicht besser wenn die die wichtigen HW-Geräte eine höhere Priorität als die weniger wichtigen HW-Geräte haben?

Im Prinzip passiert das ja schon so automatisch. Denn die Threads der IRQ-Handler werden definitiv in der Reihenfolge ausgeführt in der die IRQs auftreten (FIFO). Die Zeitscheibe sollte dann im Schnitt lang genug sein, dass die meisten Handler schon vorher abgeben (da sollten doch eigentlich ein paar ms reichen oder?).

Wäre es nicht besser wenn die die wichtigen HW-Geräte eine höhere Priorität als die weniger wichtigen HW-Geräte haben? Und wäre es nicht praktisch wenn die Priorität der HW-Geräte sich dynamisch nach der Wichtigkeit der von ihnen momentan bearbeiteten Aufgaben richtet?

Jein Wie gesagt, ich betrachte z.B. Audio/Video als verdammt wichtig, da macht es schon nen Unterschied ob da alles zur richtigen Zeit passiert. Wenn die Tastatur/Maus die Daten mal ein "wenig" (ms, aber ich denke eher weniger) später zur Anwendung schicken kann, ist eher verschmerzbar. Genauso HDD/ODD. Deswegen sollte halt der Treiberprogrammierer entscheiden können (bzw. halt die Priorität der IRQs) wie wichtig für das Gerät die Latenz ist.

Problem dabei ist natürlich, dass man entweder nen QM für Treiber braucht (was für ein Hobby-OS vllt noch geht, aber wenn man mal davon ausgeht das man kleiner als MS ist und nicht alle Treiber kontrollieren kann, geht es halt nicht) oder den Programmierern alles vorschreiben muss (und das geht auch nicht wirklich).
Gleiche Prinzip ist, dass ein Programm sich einfach in die höchste Priorität packen kann und schon setzt man die meisten/alle Mechanizmen aus, die eigentlich greifen sollen für ne gute User Experience.
Deswegen sollte man halt auch ganz deutlich wissen worauf man sein OS spezialisieren will (was auch ein Problem von Linux auf dem Desktop ist und wo Windows es teilweise besser macht).

Ich würde eher sagen das der Scheduler dann O(n/2) o.ä. ist weil es ja doch recht wahrscheinlich ist das einer der nächsten Threads auf der gerade aktuellen CPU als letztes gelaufen ist

Ist O(n/2) nicht gleich O(n)?

Ich komme bei der O-Notation immer durcheinander und finde die auf nem Rechner sowieso eher unpraktikabel, weil wenn man streng nach der Theorie geht, ist aufm Rechner alles O(1).

Stimmt, die Cache-Problematik sollte bei einem Single-Sockel-System gar nicht mal so schlimm werden da ja bei Intel und auch bei AMD die letzte Cache-Ebene immer für alle Cores gemeinsam gilt, kritisch werden wohl erst Mehr-Sockel-Systeme.

Das will ich bei mir durch "einige" Scheduler lösen (im Mom sind es 2, werden aber mind. 3). Zur Bootzeit wird dann entschieden welcher Scheduler genommen wird, das wird aber automatisch gemacht und kann vom User nicht so wirklich beeinflusst werden (es sei denn er deaktiviert im BIOS irgendwelche CPUs oder Kerne).

Die meisten ARM-MultiCore-SoCs haben üblicherweise pro Core einen kleinen L1-Daten-Cache und einen kleinen L1-Code-Cache aber zusätzlich noch einen großen und gemeinsamen L2-Cache für alles, von daher denke ich dass das Cache-Problem bei den heutigen ARM-MultiCore-SoCs nicht allzu bedeutend ist.

Ich sollte mich so langsam echt mal in ARM einlesen. Denn ich stelle mir gerade die Frage, woher weiß man auf ARM eigentlich wie viele Cores vorhanden sind? Es gibt ja nicht sowas wie ACPI.

[bluecode]

Ist O(n/2) nicht gleich O(n)?

Doch natürlich. Er wollte damit wohl nur genauer sagen wie man sich den konstanten Faktor vorzustellen hat.

Ich komme bei der O-Notation immer durcheinander und finde die auf nem Rechner sowieso eher unpraktikabel, weil wenn man streng nach der Theorie geht, ist aufm Rechner alles O(1).

Nur wenn man mit der Annahme, dass die Eingabe beschränkt ist, arbeitet. Unpraktikabel ist die O-Notation nur dann, wenn man mit ihr nicht das analysiert was wirklich von Interesse ist: Es zwingt ja niemand dich nur die Länge der Eingabe als Variable herzunehmen (das zieht man in aller Härte eigentlich nur für Sachen auf der Turingmaschine heran), sondern ein oder mehrere sinnvolle Größenmaße die aus der Eingabe resultieren (Anzahl Knoten oder Kanten bei Graphen, Höhe eines Baumes, maximaler Ein/Ausgrad, Baumweite etc.) und teilweise kommen da schon auch Konstanten vor, um genauer zu sagen wie die Laufzeit aussieht. ZB wäre es für eine praktische Analyse unsinnig ein 2^(2^k) wegzulassen (für konstantes k). Abgesehen davon muss man auch nicht die worst-case Laufzeit abschätzen, man kann auch average/best-case abschätzen.
Das alles sagt am Ende natürlich immernoch nichts über die konkrete praktische Performance. Es ist aber ein ziemlich gutes Maß dafür wie stark die praktische Performance bei Vergrößerung der Eingabe abnimmt.Insofern ist es schon nützlich, wenn man nicht vorher genauer weiß wie groß die Eingabe sein wird und nicht die Zeit hat/investieren will alle Datenstrukturen die einem so einfallen zu implementieren und gegeneinander zu testen.

[FlashBurn]

Das alles sagt am Ende natürlich immernoch nichts über die konkrete praktische Performance. Es ist aber ein ziemlich gutes Maß dafür wie stark die praktische Performance bei Vergrößerung der Eingabe abnimmt.Insofern ist es schon nützlich, wenn man nicht vorher genauer weiß wie groß die Eingabe sein wird und nicht die Zeit hat/investieren will alle Datenstrukturen die einem so einfallen zu implementieren und gegeneinander zu testen.

Genau da liegt das eigentliche Problem bei der Anwendung der O-Notation.

Du kannst nicht einfach davon ausgehen das O(1) immer schneller ist als O(n) (nur ein Bsp), was aber eigentlich jeder macht, der entweder nicht viel Erfahrung hat oder es nicht besser gelernt hat (was an Unis leider der Fall ist).

Man muss sich immer genau angucken, wie lange dauert O(1) und wie lange dauert O(n) (meinet wegen auch nur im worst-case). Es kann nämlich durchaus sein, dass der O(n) in der Praxis, für die jeweilige Anwendung, schneller ist als O(1).
Was nämlich leider nicht so wirklich in der Uni rübergebracht wird ist, dass die O-Notation nix mit der eigentlichen Laufzeit zu tun hat.

[bluecode]

[...], was aber eigentlich jeder macht, der entweder nicht viel Erfahrung hat oder es nicht besser gelernt hat (was an Unis leider der Fall ist).

Du kannst es nicht einfach auf die Theorie schieben, wenn jemand sie missversteht. Genauso schiebe ich es nicht auf die Datenstruktur, wenn jemand sie schlecht implementiert. Andererseits ist die verkürzte/missverstandene Version der Theorie eine für die meisten Situationen bei weitem ausreichende Grundlage, soll heißen für die meisten UseCases (variable Größe der Eingabe im nicht-trivialen Bereich) und die bekanntesten Datenstrukturen stimmt das auch mit der Realität überein.

Ich denke übrigens schon, dass es an der Uni gelehrt wird. Ob es dann auch gelernt wird, ist eine andere Frage (und eine die nicht unbedingt den Profs in die Schuhe zu schieben ist). Aber selbst wenn es nicht gelernt wird, ich halte die O-Notation für eine der besseren Entscheidungsgrundlagen (im speziellen besser als alles für Eingabegröße k für kleines k zu testen, wenn in der Realität auch größere k auftreten, das es beim osdev häufig nur kleine k's gibt ist ein anderes Thema). Aber um es gleich mit dazu zu sagen, wenn man es richtig machen will, dann abstrahiert man das was man als Datenstruktur braucht so, dass man die Implementierung in der richtigen Phase des Entwicklungszyklus durch etwas in der Praxis performanteres austauschen kann (das man dann aber auch auf Praxisfällen testet! Genau hier wirds ja dann beim OSDev zB richtig schwierig, denn man kann jahrelang nichts praxisrelevantes richtig testen und im speziellen nicht die vielen tollen Spezialfälle die ihr hier so gerne an den Haaren herbeizieht). Deswegen würde ich lieber anfangs asymptotisch auf der sicheren Seite sein, wenn ich nichts/wenig an Daten (was Eingabegrößen und Laufzeitvergleiche diverser Datenstrukturen für diese Größe angeht) über das konkrete Anwendungsgebiet habe.

[FlashBurn]

Du kannst es nicht einfach auf die Theorie schieben, wenn jemand sie missversteht.

Da hast du natürlich recht, aber der Punkt bleibt, dass theoretisch alle Algos auf dem Rechner O(1) sind

Ich denke übrigens schon, dass es an der Uni gelehrt wird. Ob es dann auch gelernt wird, ist eine andere Frage (und eine die nicht unbedingt den Profs in die Schuhe zu schieben ist).

Also ich habe den Spaß jetzt an 2 verschiedenen Unis hören dürfen und es wurde beides Male nicht darauf hingewiesen. Ich gehe aber davon aus, dass die Profs einfach voraussetzen, dass man das weiß oder sich denken kann

[bluecode]

Du kannst es nicht einfach auf die Theorie schieben, wenn jemand sie missversteht.

Da hast du natürlich recht, aber der Punkt bleibt, dass theoretisch alle Algos auf dem Rechner O(1) sind

Die Annahme ist genauso sinnvoll wie "in der Praxis gibt es nur endlich viele natürliche/reelle Zahlen". Ich denke wir sind uns beide einig, dass das kein hilfreiches Konstrukt wäre und keine weltbewegenden Aussagen möglich machen würde.
Es macht halt keinen Sinn Annahmen zu machen, die die Analyse zu grobkörnig ausfallen lässt (also alles als gleich zu behandeln was man eigentlich unterscheiden wollte). Im Endeffekt ist die obige Folgerung ja genauso viel wert wie "alle terminierenden Algorithmen terminieren". Und das einzige wonach man sinnvoll rechnerunabhängig unterscheiden kann ist halt nunmal das Wachstum der Laufzeit in Abhängigkeit der Eingabegröße (bis auf Konstanten, genau wegen der Rechnerunabhängigkeit). Und die Praxis zeigt imho überwältigend, dass diese Art der Analyse sehr wertvoll ist.

[FlashBurn]

Ich denke wir sind uns beide einig, dass das kein hilfreiches Konstrukt wäre und keine weltbewegenden Aussagen möglich machen würde.

Jap, nur leider durfte ich schon einige Diskussionen erleben wo halt genauso argumentiert wurde, dass wenn das größte n bekannt ist, der Algo in dem Fall O(1) ist und das war in einem anderen OS-Dev Forum

[erik.vikinger]

Hallo,

Das macht das Problem für mich noch unverständlicher.

Soweit ich weiß können Windows-Sound-Treiber gewisse Vorgaben für die Puffergröße machen an die sich die Programme aber nicht sklavisch halten müssen. Vielleicht hat sich da von einer Treiber-Revision zur nächsten Revision was geändert. Ansonsten kann ich zu Deinem Problem gar nichts sagen weil ich Dein Problem ja nicht kenne. Vielleicht solltest Du das in einem Forum posten wo es um die von Dir benutze Hardware oder OS-Version geht.

Hmm, darüber müssen wir diskutieren

Sehr gerne.
Hauptsache ich muss nicht über O's diskutieren.

Also ich bin der Meinung alle IRQs sollten erstmal behandelt werden, damit es halbwegs schnell weitergehen kann.

Das sehe ich grundlegend anders. Ich finde alles mit niedriger Priorität muss solange warten bis alles mit hoher Priorität abgearbeitet ist, dazu sollte noch eine kleine Fairnessregel kommen damit auch die Dinge mit niedriger Priorität nicht ganz verhungern. Wenn Du alle IRQs auf die CPU lässt ohne nach Priorität zu sortieren dann werden die wichtigen Sachen eventuell zu stark gebremst und es kommt zu genau dem was Du eigentlich nicht möchtest: Aussetzern.

Allerdings habe ich bei mir auch die Möglichkeit die Priorität der IRQs festzulegen. Da würde es dann schon Sinn machen diese Priorität auch an die IRQ-Handler weiterzugeben.

Genau.

Da bin ich halt anderer Meinung. Um mal dein Bsp. mit dem MP3-Player, der im Hintergrund läuft, aufzugreifen. Ich möchte eigentlich auch da das es zu keinen Aussetzern kommt, dann läuft halt z.B. die Kompilierung langsamer, aber die Musik läuft durchgehend. Das meine ich mit Latenz und das der Treiberprogrammierer die kennen sollte.

Du verwechselst eindeutig "zugesicherte Latenz" mit "zugesichertem Durchsatz". Im Falle des MP3-Player ist nur der Durchsatz entscheidend bzw. die akzeptable Latenz ist so groß das diese kein Problem darstellt. Ein MP3-Player arbeitet üblicherweise nach dem Double-Buffer-Prinzip: er nimmt 2 Puffer und füllt als erstes beide mit Daten (Sequenz 1 und 2) dann startet er Puffer A und kurz darauf legt er Puffer B in die Queue für den Sound-Treiber und sagt das er geweckt werden möchte wenn Puffer A abgearbeitet wurde. Sobald Puffer A abgearbeitet wurde wird der Play-Thread wieder geweckt und er befüllt Puffer A mit neuen Daten (Sequenz 3) und hängt ihn an die Sound-Queue an und lässt sich wecken wenn Puffer B leer ist. Sobald Puffer B fertig ist wird der Player-Thread erneut geweckt und befüllt Puffer B mit neuen Daten (Sequenz 4) und hängt diesen wieder an die Sound-Queue an und lässt sich wecken wenn Puffer A fertig ist. Wie das dann weiter geht kann sich sicher jeder selbst ausmalen. Zu Aussetzern kommt es wenn für das Aufwecken, befüllen eines Puffers und anschließendes Anhängen an die Sound-Queue mehr Zeit vergeht als ein Puffer lang ist (Durchsatz). Deswegen nutzen MP3-Player gerne möglichst große Puffer damit es eben auch nichts macht wenn vom Ende eines Puffers bis der Player-Thread dann tatsächlich wieder auf einer CPU läuft mal ein bisschen Zeit vergeht (Latenz) was ja aufgrund der Länge der Zeitscheiben usw. durchaus mal passieren kann. Wenn die Puffer zu kurz sind kann es passieren das unerwartet lange Latenzen beim Aufwecken zu Aussetzern führen und wenn die CPU zu schlapp ist wird es passieren das selbst bei langen Puffern nicht schnell genug nachgefüllt werden kann (wir gehen jetzt mal davon aus das die Zeit die für das Befüllen eines Puffers benötigt wird direkt linear proportional zu dessen Größe ist, was bei MP3 ziemlich zutreffend sein sollte).

An diesem Bsp. sieht man halt gut, worauf jeder Wert legt.

Eben nicht, man sieht nur ein einziges Szenario von vielen. Ich kann mir z.B. eine Messdatenerfassung per USB (mit sehr hoher Baudrate) und das direkte abspeichern auf die HDD vorstellen und so lange das läuft ist es mir absolut egal ob der Ton kurz aussetzt oder der Bildaufbau mal ein paar Frames länger dauert. Mir ist wichtig das ich als User sagen kann was wichtig ist und eben nicht der Treiberprogrammierer, der weiß doch gar nicht was ich mit meinem PC machen will.

es geht mir dabei um den Treiber, nicht um das Programm welches die Daten für den Treiber erzeugt.

Das darf man nicht voneinander trennen. Der Treiber ist nur ein untergeordneter Dienstleister, der User arbeitet mit Programmen und von denen möchte er bestimmte Aufgaben erfüllt bekommen. Diese Programme benutzen ihrerseits wieder die Treiber aber hier ist es wichtig dass das Programm sagen kann welche (Teil-)Aufgabe wie wichtig ist. Stell Dir vor während einer meiner Datenerfassungen würde irgendein Ereignis passieren das einen kurzen Ton ausgibt und nur weil der Sound-Treiber grundsätzlich mit extrem hoher Priorität läuft würde der Datenstrom kurz unterbrochen, ich nehme an Du kannst Dir vorstellen wie begeistert ich dann über den Sound-Treiber wäre. Wie taljeth schon sagte "Der Kernel sollte nur den Mechanismus anbieten, aber nicht die Policy vorschreiben.", wobei hier jetzt "Kernel" gegen "OS mitsamt Treiber" auszutauschen ist.

Denn die Threads der IRQ-Handler werden definitiv in der Reihenfolge ausgeführt in der die IRQs auftreten (FIFO).

Die IRQs kommen mehr oder weniger zufällig, daraus sollte man nichts schließen. Und wenn Du streng nach FIFO arbeitest könnte es doch passieren das Treiber für nachfolgende IRQs warten müssen nur weil ein Treiber weiter vorne ewig braucht.

Die Zeitscheibe sollte dann im Schnitt lang genug sein, dass die meisten Handler schon vorher abgeben (da sollten doch eigentlich ein paar ms reichen oder?).

Also ich kann mir auch mal komplexe Workloads vorstellen wo der Handler mal deutlich mehr als eine Zeitscheibe braucht. Du machst da wieder Annahmen und Vereinfachungen wo es nicht angebracht ist.

ich betrachte z.B. Audio/Video als verdammt wichtig, da macht es schon nen Unterschied ob da alles zur richtigen Zeit passiert.

Ich habe aber auch Situationen, z.B. Messdatenerfassung, wo mir Audio/Video absolut scheiß egal sind, wenn ich aber gerade ein Full-HD-Video schaue ist mir Audio/Video (vor allem auch das beides Synchron ist) doch wieder wichtig. Deswegen will ich ein OS das sich meinen Anforderungen anpassen lässt. Was eine "gute User Experience" ist hängt sehr davon ab was der User machen will, ein OS das nur mit ein paar willkürlich handverlesenen Workloads zurecht kommt dürfte sich nicht lange am Markt halten können.

das wird aber automatisch gemacht und kann vom User nicht so wirklich beeinflusst werden

Warum nicht? Da eine kleine Stellschraube vorzusehen kostet Dich fast nichts und würde dem User die Möglichkeit geben für spezielle Situationen auch mal spezielle Vorgaben zu machen.

Denn ich stelle mir gerade die Frage, woher weiß man auf ARM eigentlich wie viele Cores vorhanden sind?

Das weiß normalerweise der Board-spezifische Bootloader und der sagt es dem OS.


Grüße
Erik

[FlashBurn]

Soweit ich weiß können Windows-Sound-Treiber gewisse Vorgaben für die Puffergröße machen an die sich die Programme aber nicht sklavisch halten müssen. Vielleicht hat sich da von einer Treiber-Revision zur nächsten Revision was geändert. Ansonsten kann ich zu Deinem Problem gar nichts sagen weil ich Dein Problem ja nicht kenne. Vielleicht solltest Du das in einem Forum posten wo es um die von Dir benutze Hardware oder OS-Version geht.

Der Versuch das zu klären ist schon vor längerer Zeit gescheitert. Es hat auch nix mit dem Audio-Treiber zu tun, der tut hier auf meinem Laptop auch seinen Dienst. Zumal auch der Video-Treiber davon betroffen scheint (da in dem Moment auch das Bild kurz "stockt" bzw. es werden Frames ausgelassen).

Was mir so beim Lesen deines Beitrags aufgefallen ist, wir reden mal wieder von unterschiedlichen Dingen. Bei mir laufen (bisher) alle IRQ-Handler mit der selben Real-Time-Priorität. Das ist ja nur die eine Richtung, nämlich das Empfangen von Daten/Ereignissen. Diese Handler sollten ungefähr ähnlich denen von einem Monolithen aussehen.

Um weiter das Bsp. mit dem MP3-Player zu nutzen und wo im Vordergrund ne Kompilierung läuft (am besten eine CPU, macht das ganze einfacher). Unter Windows ist es ja so, dass Anwendungen die im Vordergrund sind einen gewissen Bonus bei der Zeitscheibe bekommen. Funktioniert der Scheduler so, dass immer die Threads mit höchster Priorität laufen und am Ende ihrer Zeitscheibe wieder hinten an die Ready-Liste gepackt werden, wird der MP3-Player entweder nie oder nur zu sporadisch drankommen.
Dem könnte man entkommen, in dem z.B. der Worker-Thread ne höhere Priorität als Normal bekommt. Nun funktioniert mein Scheduler noch anders, bei mir wird ein Thread der seine Zeitscheibe aufgebraucht hat nicht hinten an die Ready-Liste, sonder an die Run-Liste gehängt. Erst wenn die Ready-Liste einmal abgearbeitet wurde, werden die beiden Listen vertauscht (wobei die Ready-Liste ja leer ist) und es wird wieder von Vorne angefangen. So verhungert zumindest kein Thread. Da bräuchte man das mit der höheren Priorität z.B. gar nicht. (Ob das so ne gute Idee ist, steht auf nem anderen Blatt.)

Ich kann mir z.B. eine Messdatenerfassung per USB (mit sehr hoher Baudrate) und das direkte abspeichern auf die HDD vorstellen und so lange das läuft ist es mir absolut egal ob der Ton kurz aussetzt oder der Bildaufbau mal ein paar Frames länger dauert. Mir ist wichtig das ich als User sagen kann was wichtig ist und eben nicht der Treiberprogrammierer, der weiß doch gar nicht was ich mit meinem PC machen will.

Der Treiberprogrammierer weiß schon wie wichtig was ist, schließlich legt er auch fest welche Priorität der IRQ bekommt.
Problem auf Empfangsseite ist, dass du die Priorität des direkten IRQ-Handlers nur einmal festlegen kannst (da wo der Treiber sich registriert) und dann kannst du eigentlich keinen Einfluss mehr darauf nehmen. Denn du weißt ja auch nicht wer die Daten dann haben möchte und wie wichtig die nun sind.

Auf Sender-Seite (Daten werden vom User an den Treiber gegeben), sieht das schon anders aus. Dass kann man dadurch beeinflussen, dass man versucht durchgehend die Priorität des Caller´s weiter zu nutzen. Ich würde da auch gerne die Variante von Windows mit nutzen, sprich das ein Programm das im Vordergrund ist, nen Priorität-Boost bekommt. Die Frage ist aber auch da, wie kann man das vernünftig umsetzen. Man müsste dafür ja eigentlich nen Syscall machen, dass der GUI-Server (oder auch TUI-Server) einem Prozess einen gewissen Prioritäts-Boost geben kann (was dann für alle Threads des Prozesses gelten würde). Mir fällt im Mom keine Anwendung ein, aber was ist wenn eine Anwendung einen Thread hat, der die Idle-Priorität hat (der Thread läuft nur, wenn normalerweise der Idle-Thread laufen würde) und der bekommt miteinmal solch einen Boost. Das ist dann ja nicht mehr im Sinne des Programmierers.

Die IRQs kommen mehr oder weniger zufällig, daraus sollte man nichts schließen. Und wenn Du streng nach FIFO arbeitest könnte es doch passieren das Treiber für nachfolgende IRQs warten müssen nur weil ein Treiber weiter vorne ewig braucht.

Das die anderen Treiber nicht verhungern, soll ja durch eine entsprechend "kurze" Zeitscheibe gesichert werden. Deswegen sollte der Treiberprogrammierer auch so wenig wie nötig direkt im IRQ-Handler machen.

Warum nicht? Da eine kleine Stellschraube vorzusehen kostet Dich fast nichts und würde dem User die Möglichkeit geben für spezielle Situationen auch mal spezielle Vorgaben zu machen.

Naja, was heißt kostet mich nix, mein Bootloader müsste geändert werden und ich müsste dafür etwas in meiner Config-Datei für den Bootloader vorsehen

Ich meine gut, man könnte den User in dieser Config-Datei wählen lassen und wenn der Scheduler nicht verfügbar ist, wird wieder automatisch gewählt. Ein anderes Problem ist aber, das mein Bootloader in dem Sinne keine Ahnung hat, welcher Scheduler was kann und was nicht, das code ich fest ein. So kann es also passieren das der User den Scheduler für Single-CPU Systeme ausgewählt hat, aber auf einem SMP-System funktioniert das nicht und das OS wird crashen. Das finde ich eher nicht so toll.

Zur Laufzeit umstellen will ich mir nicht antun.

Das weiß normalerweise der Board-spezifische Bootloader und der sagt es dem OS.

Da muss ich mal wieder Linux-Bashing betreiben. Einige in der Linux-Welt regen sich im Moment über UEFI und secure-boot auf, aber das die ganzen ARM-Boards mit Linux-spezifischen Bootloader versehen werden, stört keinen (ganz speziell fällt mir da jetzt der Bootloader vom Raspberry Pi ein)

[Svenska]

Hallo,

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

Ich dachte eher an die Labore in der Uni, aber auch hier ist auf der anderen Seite der Wand ein großer Kasten... mit Sicherungen drin. Auch die darf man für gewöhnlich als Not-Aus bezeichnen.

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.

Auf jedem, bei dem der User bewusst ist, dass es so einen Default gibt. Das gilt überall.

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

Das mag sogar sinnvoll erscheinen. Aber ebenfalls ist es sinnvoll, diese Zahl änderbar zu machen. Schließlich kann dein System auch an stellen eingesetzt werden, wo du extrem viele Threads mit extrem geringen Latenzanforderungen hast, während gleichzeitig CPU-fressende Threads laufen. Dann sind vielleicht 25% angemessen. Der Administrator, der so ein System betreiben möchte, wird dann den Default kennen und eventuell auch ändern wollen. Für den Durchschnittsnutzer reicht der Default aus.

Warum nicht? Da eine kleine Stellschraube vorzusehen kostet Dich fast nichts und würde dem User die Möglichkeit geben für spezielle Situationen auch mal spezielle Vorgaben zu machen.

Naja, was heißt kostet mich nix, mein Bootloader müsste geändert werden und ich müsste dafür etwas in meiner Config-Datei für den Bootloader vorsehen

Ja, weil du dein Design so verbockt hast, dass die Flexibilität jetzt fehlt. Aber wenn du der Meinung bist, dass dein System besser ist als jedes andere, dann musst du es nicht einstellbar machen. Die Praxis zeigt, dass Stellschrauben immer gut sind.

Das weiß normalerweise der Board-spezifische Bootloader und der sagt es dem OS.

Da muss ich mal wieder Linux-Bashing betreiben. Einige in der Linux-Welt regen sich im Moment über UEFI und secure-boot auf, aber das die ganzen ARM-Boards mit Linux-spezifischen Bootloader versehen werden, stört keinen (ganz speziell fällt mir da jetzt der Bootloader vom Raspberry Pi ein)

Also die GPU zum Booten zu benutzen ist schon heftig, da stimme ich dir zu. Aber du darfst auch gerne 25% auf den Kaufpreis und 10% auf die mechanische Größe drauflegen und ein kleines Boot-Flash anbauen... die Frage ist, ob du dazu bereit bist.

Linux (neben Windows CE) ist auf den meisten ARM-Systemen ein Standard und danach haben sich die Betriebssysteme zu richten. Was beim PC ein Teil von ACPI ist, sind in der ARM-Welt z.B. FTDs (Flatted Device Trees). Ein Hobby-OS muss damit klarkommen. Reg dich lieber drüber auf, dass man einen WindowsCE-Bootloader in der Regel nicht dazu überreden kann, etwas anderes zu booten, einen üblichen Linux-Bootloader (RedBoot, U-Boot) dagegen schon eher. Und die findet man häufiger.

PS: Bei MIPS ist das noch viel schlimmer. Da ist ja nichtmal die Architektur festgelegt. Guck dir mal Projekte wie z.B. Linux auf der Playstation 2 an... außerdem wollen die Hersteller oft genug keine anderen Betriebssysteme, im Gegensatz zum PC, vergleiche hierbei die Diskussion von TomTom damals.

Gruß,
Svenska

[FlashBurn]

Ja, weil du dein Design so verbockt hast, dass die Flexibilität jetzt fehlt.

Was meinen Bootloader betrifft, definitiv Der müsste mal komplett überarbeitet werden. Allerdings wären wir da wieder bei KISS Im Mom brauche ich keine speziellen Sachen für meine Kernel-"Module" und so wollte ich es eigentlich lassen. Sowas kann man immernoch ändern, ohne das es Probleme gibt (außer das mit dem Wechseln zur Laufzeit).

Aber wenn du der Meinung bist, dass dein System besser ist als jedes andere, dann musst du es nicht einstellbar machen. Die Praxis zeigt, dass Stellschrauben immer gut sind.

Ich will kein zweites Linux machen! Was ich mir wünsche ist erstmal ein DAU-kompatibles System (und ich denke das ist schwieriger als nen System für Freaks) und da muss man keine Scheduler per Hand wechseln können. Mein OS soll auch nicht auf jedem Toaster laufen

Linux (neben Windows CE) ist auf den meisten ARM-Systemen ein Standard und danach haben sich die Betriebssysteme zu richten.

Dann sollen die Linux-Leute auch nicht zwecks secure-boot rumheulen, Windows ist auf PC-Systemen nun mal Standard Ok, ist auch scheiße für uns.

Reg dich lieber drüber auf, dass man einen WindowsCE-Bootloader in der Regel nicht dazu überreden kann, etwas anderes zu booten, einen üblichen Linux-Bootloader (RedBoot, U-Boot) dagegen schon eher.

Dafür bräuchte man an der richtigen Stelle nen dislike-Button

Welche Geräte gibt es heute die nur WindowsCE laden können (gut gibt ein paar billig Netbooks aus Fernost)? Ich möchte meinen der Fastboot-Bootloader von Android ist auch nicht so das wahre, aber ich würde mir viel lieber eine allgemeine Firmware wünschen, wo ich nicht schon im Bootloader alles mögliche an Treiber haben muss (ein BIOS nur in besser ).

außerdem wollen die Hersteller oft genug keine anderen Betriebssysteme, im Gegensatz zum PC, vergleiche hierbei die Diskussion von TomTom damals.

Ich denke das würde sich mit einer allgemeinen Firmware auch lösen lassen. Problem außerhalb des PCs ist doch das man das System relativ einfach zerschießen kann, aber es relativ schwer wieder in Ordnung bekommt.

[kevin]

Ja, weil du dein Design so verbockt hast, dass die Flexibilität jetzt fehlt.

Was meinen Bootloader betrifft, definitiv Der müsste mal komplett überarbeitet werden.

Nein, sowas! Wie konnte das nur passieren? Ein selbstentwickelter Bootloader mit kaputtem Design, der die Flexibilität einschränkt. Also damit konnte ja wirklich niemand rechnen!!11elf! (Hier steht es im Wiki)