Guten Morgen liebe UbuntuuserInnen,
gibt es die Möglichkeit, einem Program Priorität zuzuweisen, wieviel CPU last es maximal nutzen darf?
![]() Anmeldungsdatum: Beiträge: 1549 Wohnort: /home/micha |
Guten Morgen liebe UbuntuuserInnen, gibt es die Möglichkeit, einem Program Priorität zuzuweisen, wieviel CPU last es maximal nutzen darf? |
![]() Anmeldungsdatum: Beiträge: 19197 |
Hi. Das kennst du nach 600 Beiträgen noch nicht? 😲 Es gibt da so eine Suchmaschine im Internet, wenn man da seine Frage eingibt kommt fast immer die passende Webseite: http://www.google.com/search?q=ubuntu+cpu+priorit%C3%A4t PS: ich hoffe es ist Ok, dass ich als Ubuntuuser geantwortet habe 😉 |
![]() Anmeldungsdatum: Beiträge: 196 Wohnort: München |
Schau mal nach "renice". Damit kannst Du zwar die "Prioritäts-Sollwerte" anpassen, aber keine Prioritäten derart festnageln, dass das Betriebssystem keine Chance hätte, deine Regeln auszuhebeln. Wenn Du einen Performance-Test durchziehen willst und jeden Einfluss des Schedulers ausschliessen willst, bin ich mit meinem Latein am Ende. Seit längerem suche ich selbst nach einer "billigen" Lösung. Auf der blanken Hardware aufzusetzen klingt irgendwie nach zuviel Arbeit. |
![]() Anmeldungsdatum: Beiträge: 19197 |
Was bringen Benchmarkwerte, die nicht unter realen Bedingungen gemacht wurden, wer lässt den sein Linux ohne Scheduler und Hintergrunddienste laufen? Wenn du unbedingt irgendwelche Peakwerte zum Angeben brauchst kannst du ja im Recoverymodus testen, da läuft fast nix nebenbei. |
(Themenstarter)
![]() Anmeldungsdatum: Beiträge: 1549 Wohnort: /home/micha |
Vielen Dank lieber UbuntuUser ☺ UbuntuuserInnen bedeutet das gleiche wie "Ubuntuuser/innen" ←- so schreibt man das neuerdings nicht mehr. Sehe immer öfter die neue Schreibweise von UserInnen statt User/innen oder so ... Danke für Eure Hilfe. LG Lupo |
![]() Anmeldungsdatum: Beiträge: 999 Wohnort: zwischen den ohren |
Renice setzt ja nur die Priorität im Verhältnis zu anderen Prozessen, und beschränkt nicht die maximale Rechenzeit. Schau' dir mal das Paket "cpulimit" an, das kommt deinen Umschreibungen nahe ☺ |
![]() Anmeldungsdatum: Beiträge: 19197 |
Man kann auch einfach User schreiben, das ist ein englisches Wort und ist für beide Geschlechter das Gleiche. Mit dem großen I ließt es sich immer so, als würde da ein kleines i stehen. Was wiederum die Männer vernachlässigt, die in letzter Zeit ganz schön unterdrückt und benachteiligt werden. |
![]() Anmeldungsdatum: Beiträge: 196 Wohnort: München |
Ich habe aus einem ohnehin schon schnellen Algorithmus in einer Art Kleinkrieg nochmal 7% raus gekitzelt oder genauer: Ich komme auf ungefähr 7%, wenn ich zu erwartende Maschinenbefehle abzähle, welche natürlich vom verwendeten Compiler abhängen. 7% sind aber so wenig, dass ich erhebliche Datenmengen durch den Algorithmus jagen muß, bis ich einen echten Unterschied messen kann. Wenn ich das mache, verhageln mir die Hintergrundprozesse das Messergebnis manchmal derart, dass das Original gegebenenfalls schneller als die optimierte Version ist. Gerne würde ich einen Nachweis dafür liefern, dass die optimierte Version mehr oder weniger unabhängig von verwendeten Compiler stets schneller ist. Verschachtelte Schleifen und Kaskaden von bedingten Anweisungen machen das ungefähre Abzählen von Maschinenbefehlen (in der Source) schwer. Der Recoverymodus ist eine klasse Idee. Danke. Nur so als ergänzenden Vorschlag: Wie wär's, wenn man auf einem Mehr-Kern einen Kern exklusiv bunkern könnte? Bedingt natürlich einen statten Eingriff in den OS-Kernel. Diese Feature wäre vielseitig verwendbar und wurde MS ziemlich blass aussehen lassen. |
![]() Anmeldungsdatum: Beiträge: 999 Wohnort: zwischen den ohren |
Was soll genau der Sinn von sowas sein? Ich meine, ausser für bestimmte embedded/controller-Szenarien läuft ein Programm doch immer mit anderen Prozessen im Hintergrund - mal mehr, mal weniger, und sei's nur der Kernel. Ausserdem gibt es z.B. auf dem Desktopmarkt eine ganze Bandbreite verschiedener Prozessoren, die sich in bestimmten Punkten unterscheiden: Cachegrössen zum Beispiel, wo man mit gezielten Optimierungen bei "Speicherintensiven" Algorithmen durch Packetierung/Aufteilungen viel holen kann, aber nicht jeder Prozessor hat gleichviel/gleichschnellen Cache, und Hintergrundprozesse können immer eine unbestimmte Grösse "zerblasen". Dann das Instruction-Reordering und Parallelausführung innerhalb eines Kerns im Prozessor, die reine Taktzahl der Assemblerbefehle wird so schwer vorhersehbar, ausser man rechnet für eine bestimmte Architektur gezielt. Intel's Hyperthreading und die art wie Bulldozer/Llano von AMD Ressourcen zwischen CPU-"Modulen" Teilen fügen auch einen schönen Teil Mondphasenabhängigkeit hinzu. Was Branching angeht, bei "zufälligem" Sprungverhalten konnte ich, zumindest früher zu Pentium II-Zeiten, bei einfachen Algorithmen durch das Verhindern von Sprüngen allgemein (z.B. Alles berechnen, per Bitmasken das Ergebnis zwischen Möglichkeiten konditional maskieren) viel 'rausholen. Das einzige was hilft ist viel "Faustwissen" über die Architekturen, für die Extraleistung erforderlich ist, und Testen unter den verschiedensten Bedingungen, und zwar "statistisch". Grade gute Cachenutzung ist meist ein Riesenbeschleuniger, aber eben schwer vorhersehbar. Dass ein Programm einen Kern nur für sich hat, ohne Interrupts und andere Threads mag für Extremkitzeleien witzig sein, so wie extremes Overclocking, aber eben total praxisfern. Aber hier ging es ja schätze ich eher darum, Programme, die im Hintergrund laufen in die Schranken zu weisen, damit Vordergrundprozesse reaktiv bleiben, von daher ist so eine Diskussion hier eher müssig, und gehörte eigentlich nach "shell und programmieren". |
![]() Anmeldungsdatum: Beiträge: 196 Wohnort: München |
Daran Hintergrundprozesse in die "Schranken zu weisen" dachte ich eigentlich weniger. Die sollen weiter laufen. Es geht eher, darum für bestimmte Aufgabe Ausführungszeiten zu garantieren und/oder vorhersagbar zu machen. |
![]() Anmeldungsdatum: Beiträge: 999 Wohnort: zwischen den ohren |
Sec, google mal nach "linux core shielding", "linux cpu affinity", und schau dir RT-Priorities/scheduler an. Zusammen mit "threadirqs" und der affinity sollte man eigentlich auf einem multicore system recht "direkte" Werte erzeugen können, wenn man einem (single-thread) Prozess RT-Priorität 99 gibt, dafür sorgt, dass alle softirqs drunter liegen, und der 99'er Prozess per affinity auf einen Kern gesperrt wird. Aber 100,00% ausführungszeit kriegt der so bestimmt immer noch nicht (wer weiss was der Kernel so macht, und "hardirqs"...bin jetzt aber kein TuX X-Perte), weitergehend sind da also die "Shielding"-Lösungen, die Kerne komplett aus dem Kernel nehmen (auch keine irq's mehr), und nur explizit gewählten Prozessen zugriff auf sie geben. Ist aber eher für extreme Echtzeit-Anforderungen gedacht, und nicht zum benchen von software, aber gut - deine Idee ist an sich nicht verkehrt. Auch wenn bei'm benchmarken von Optimierungen selbst unter nichtausschliessung von multitasking recht gute ergebnisse durch schlichte wiederholung/ausdehnung und statistik der ausführzeiten des codes zustandekommen. Bedenke auch: hat so'n Prozess unter einem reservierten Kern superzeiten, können die unter "Normalbedingungen" auf derselben cpu immer mal einbrechen, wenn die Cacheausnutzung eben am Limit war - was "parallel" auf dem gleichen Kern läuft, hat auch so sein Anrecht auf die Cachelines vom L1 und L2. Vielleicht zum reinen Profilen eine Lösung mit einem Emulator, der die Taktzyklen genau protokollieren kann? Der Müsste aber "gute" Daten zu allen möglichen Architekturen, Cacheverhalten, RamBusgeschwindigkeiten/-Latenzen, usw... haben. Das fände ich, selbst als Hobbyfreak, auch ein spannendes Tool in punkto Optimierungsarbeiten! Wie früher, als die Jungs von ID-Software alu und fpu gemixt haben, um maximalen Durchsatz bei Quake zu bekommen! 🦆 |