Nachrichten

61

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 21:19 »

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)

Wie soll ich es nur sagen ... das was GRUB mir bieten kann funktioniert Das was mir GRUB nicht bieten kann, ist halt nicht so flexibel wie es sein könnte. Ich habe mich für einen eigenen Bootloader entschieden, weil ich da alles kontrollieren kann, Erfahrung sammle, es spaß macht daran rumzubasteln (du weißt schon, das viele alleine die Bastelei als das fertige Ergebnis interessiert?) und weil ich mir so die 3.-Stage im Bootvorgang sparen konnte.

Interessant finde ich aber folgendes:

Falls man allerdings von Anfang an intensiv seinen Bootloader plant – was einem Anfänger aufgrund mangelnder Erfahrung verwehrt bleibt

Soll heißen, eigentlich sollte man auch kein OS programmieren (oder planen). Denn das kann ja ein Anfänger nicht aufgrund mangelnder Erfahrung. Henne-Ei-Problem (vorallem was den Bootloader betrifft, da man heutzutage ja nix mehr im Real-Mode macht).

62

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 19:50 »

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.

63

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 17:59 »

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)

64

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 16:02 »

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

65

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 15:38 »

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

66

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 13:54 »

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.

67

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 13:07 »

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.

68

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 05. November 2011, 16:32 »

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.

69

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 05. November 2011, 15:03 »

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).

70

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 05. November 2011, 12:32 »

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.

71

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 04. November 2011, 14:17 »

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

72

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 04. November 2011, 13:04 »

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.

73

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 04. November 2011, 11:59 »

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.

74

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 03. November 2011, 13:22 »

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.

75

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 03. November 2011, 11:53 »

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.

76

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 02. November 2011, 22:17 »

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

77

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 02. November 2011, 20:48 »

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

78

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 02. November 2011, 20:02 »

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.

79

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 02. November 2011, 19:14 »

Ja, meine Zeitscheiben sollen auch mehrere ms lang sein (ich dachte so an 10 ms bis etwa 20 ms)

Was genau meinst du eigentlich mit Zeitscheibe, weil man da ja schon zw. periorischen Timer-IRQs und One-Shot-IRQs unterscheiden muss. Denn ich habe im Mom glaube eine max. Zeitscheibe für einen Thread von 62ms. Wenn du bei einem periodischen IRQ eine Zeitscheibe von 1ms hast, könnte man damit noch leben.

Nö, ich würd einfach die nächsten X CPUs in den Scheduler zwingen, wobei X die Anzahl der neuen Threads ist welche eventuell noch einen kleinen Angstfaktor dazu bekommt. Das ist O(n), genauso wie das Verschicken von X IPIs.

Der Punkt ist, das versenden einer IPI Nachricht um alle CPUs in den Scheduler zu zwingen ist nicht O(n), sondern O(1). Denn du versendest genau eine Nachricht. Genau ein paar CPUs in den Scheduler zu zwingen ist hingegen wieder O(n). Obwohl man auch das durch geschickten Einsatz einiger APIC Features bestimmt auf O(1) drücken kann.

Ich kenne mich bei x86 ja nicht mehr so gut aus aber wimre hat jeder APIC (auch die lokalen) eine individuelle physische Adresse

Nope, sind standardmäßig alle an die selbe Adresse gemappt. Wäre aber mal interessant zu wissen ob man durch verschiedene Adressen an die APICs der anderen CPUs ran kommt, aber da sehe ich ohnehin keinen Sinn drin.

und betrachte sowas auch nicht als Over-Engineering

Um ein wenig zu sticheln, also ist das jetzt doch Abhängig von der Sichtweise

Den Automatismus zu fixen ist die bessere Lösung, aber nicht immer möglich oder praktikabel.

Das KISS-Prinzip entstammt ursprünglich dem Bereich der Informatik. Als Designprinzip beschreibt es im Gegensatz zu einer Problemlösung in der Form eines Workarounds die möglichst einfache, minimalistische und leicht verständliche Lösung eines Problems, welche meistens als optimal angesehen wird.

Festpinnen ist also ein Workaround und ist laut dieser Definition nicht KISS.

Zumal man an dieser Definition auch schön sieht, dass KISS sehr wohl im Auge des Betrachters liegt:

leicht verständliche Lösung eines Problems, welche meistens als optimal angesehen wird

Also leicht verständlich ist mehr als nur subjektiv und "meistens" hilft da auch nicht wirklich

80

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 02. November 2011, 18:29 »

Ich hab mal als Faustregel gelesen, dass man einen RAM-Zugriff so behandeln sollte, wie man früher einen HDD-Zugriff für Swap behandelt hatte, weil es so extrem viel langsamer ist als über den Cache zu gehen. Das heißt, dass Cache extrem wichtig ist.

Daraus lese ich heraus, des es also Sinn macht den Speicherverbrauch von Software eher zu verringern als zu vergrößern Weil so ist das gewünschte ja eher im Cache.

Und du kannst einen optimal genialen ultimativ komplexen Scheduling-Algorithmus haben und ich behaupte, dass er für gewisse Verteilungen äußerst schlecht performt. In dem Fall ist es sinnvoll, ein bestimmtes Verhalten erzwingen zu können. Das wird dich zwar auch nicht überzeugen, aber dafür ist es dein Betriebssystem.

Ich bin der Meinung, dass der genial ultimativ komplexe Scheduling-Algo so lange braucht, dass es wieder keinen Sinn macht ihn zu benutzen Und ja, ich mag das mit dem Festpinnen nicht. Macht die Sache mit dem Scheduler eher komplexer. Wieso ist da KISS nicht in Ordnung?

Ich mag es nicht, wenn ein OS alles besser weiß als ich und mir die Möglichkeiten nimmt, darauf einwirken zu können. Selbst dann, wenn ich es im Normalfall nie tun werde.

Ist das nicht Over-engineering?