Tasks einem bestimmten Kern zuordnen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moin, mal wieder eine Anfängerfrage:
    Ich habe derzeit mehrere Raspberrys B+ (also nur ein Prozessorkern) mit bestimmten Diensten im Netzwerk laufen.
    Diese Dienste werden automatisch gestartet, sobald das System hochfährt. Generell brauchen generell die nicht viel Last, nur wenn ich dann mal vom IPAD aus drucke, Minecraft daddel oder der FHEM Server ein Logfile auswertet um einen Graphen zu bauen, ist temporär eine Menge Last drauf.Wenn ich diese Dienste nun auf einem B2 konsolidieren möchte wäre es nicht verkehrt, jedem Task einen eigenen Prozessorkern zuzuordnen. Nicht dass alle auf einem Kern gleichzeitig starten. Jedenfalls sind das meine bisherigen Erfahrungen auf dem Desktop, dass die Auslastung nicht optimal verteilt wird. Ja, mir ist bewusst, dass der Flaschenhals dann wo anders liegen könnte/wird...aber bis dahin kann man ja erst einmal testen.
    Bin ich auf dem Holzweg oder hat jemand evtl. eine Idee bzw. geballtes Wissen hierzu ?

    Danke vorab.

  • Das Betriebssystem bzw der Kernel managed das bereits optimal und man sollte dort nicht zwischen funkten - tut man das trotzdem kann das negative Auswirkungen auf alles andere haben (verschlimmbessern).
    Desweiteren unterstützen viele Prozesse/Programme sowieso nur einen Kern (Thread), die kann man nicht auf mehrere Kerne aufteilen da sie dann eh nur einen nutzen würden. Es sollte aber nie vorkommen das alle Prozesse auf nur einem Kern laufen - da hast du dich denk ich verguckt.

    Es gibt zwar gewisse Ausnahmen, aber die sind dann schon speziell. Zum Beispiel wenn 2 Programme den selben Cache nutzen weil sie untereinander kommunizieren, kann eine explizite Festlegung auf den selben Core die Prozesse beschleunigen, aber heutzutage kann man davon ausgehen das solche Programme entsprechende Mechanismen inkludiert haben zu erkennen ob Multicore möglich ist und sich dann auch selber um die Zuordnung kümmern.

    Es wäre übrigens das Paket "util-linux" nicht "linux-util" :fies:

    Problem hierbei ist aber das mithilfe "taskset" der Core nicht exklusiv von nur diesem Prozess genutzt wird, sondern dann auch andere Prozesse weiterhin den Core nutzen können/dürfen - was letztlich bedeutet das du dann trotzdem nicht das erreichst was du testen möchtest. Stattdessen müsstest du daher einen Core isolieren sodass der Kernel diesen Kern nicht beliebig nutzen kann/darf. Das funktioniert aber nicht mit irgendeinem Programm sondern bedarf einem speziellen Kernel-Parameter den man folglich in /boot/cmdline.txt eintragen muss (und anschließend natürlich rebooten). Das hatte ich seinerzeit auch schon > hier < beschrieben, aber hier noch mal:

    Code
    isolcpus=0

    Damit wird Linux verboten den 1.Core zu verwenden (0 - 3 sind die cpu_id's). Zum übernehmen rebooten.
    Man kann auch mehrere Cores angeben:

    Code
    isolcpus=0,3

    Was dann den 1.Core und den 4.Core betreffen würde.

    Und hier noch eine Beschreibung zu dem Kernel-Parameter:

    Zitat


    Name
    isolcpus — Isolate CPUs from the kernel scheduler.

    Synopsis
    isolcpus=cpu_number[,cpu_number,...]

    Description
    Remove the specified CPUs, as defined by the cpu_number values, from the general kernel SMP balancing and scheduler algroithms. The only way to move a process onto or off an "isolated" CPU is via the CPU affinity syscalls. cpu_number begins at 0, so the maximum value is 1 less than the number of CPUs on the system.

    This option is the preferred way to isolate CPUs. The alternative, manually setting the CPU mask of all tasks in the system, can cause problems and suboptimal load balance

    Öffnet anschließend htop seht ihr das 1 sich langweilt.

    Anschließend kann man mithilfe des Tools taskset entweder direkt ein Programm starten und sagen welchen Core es nutzen soll. Wenn ihr also ein Programm oder Script habt was ganz alleine auf einem Core laufen soll, egal ob alle anderen gerade voll ausgelastet sind, ist das eine gute Möglichkeit :fies:
    Aber beachtet das Linux das eigentlich bereits sehr gut managed. Manuell mit taskset alles mögliche zu verstellen kann das ganze auch verschlechtern!

    Man kann ein bestimmtes Programm wie folgt einem bestimmten Core (in diesem Fall den 3.Core) startend zuweisen:

    Code
    /usr/bin/taskset -c 3 /usr/bin/mpd
  • Hi,
    vielen Dank für diesen ausführlichen Beitrag. Hiermit habe ich alle Infos, um das Thema auf erledigt zu setzen, was ich aber noch nicht gleich tue, sondern hoffe, dass sich hier noch ggf. einige Erfahrungen von anderen Mitgliedern ansammeln.

    • Offizieller Beitrag

    Es wäre doch etwas sehr vermessen zu denken das du (oder ich oder sonstwer) die Prozesse besser besser handeln kann als das BS. ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Deswegen halte ich das Thema offen, um hier Erfahrungen zu sammeln. Und kurz nochmal näheres zu dem Hintergrund: Die von mir erwähnten Prozesse CUPS mit Airprint, FHEM und Minecraft haben so lange keine hohe Prozessorlast, bis eine Interaktion durch den Benutzer erfolgt. Dann ist der Kern aber auch gleich zu 99,9% beschäftigt. Kurz: Um vom IPAD oder IPhone eine Internetseite zu drucken oder ein PDF Dokument braucht man Geduld. Ebenso wenn ich mir mit dem integrierten PDF Viewer das MagPI Magazin anschauen will, was nicht wirklich viel Spaß macht, da die Wartezeit beim Blättern einfach zu lang ist.. Nur wie bereits erwähnt, das sind alles Tasks, die erst dann Last erzeugen, wenn sie durch den User angefordert wird. Die Verteilung auf einen bestimmten Kern erfolgt aber vorab. Nach welchen Kriterien geht das Betriebssystem denn vor ? beispiel: CUPS oder Fhem sollen sich nicht mit dem PDF Viewer auf einem Kern herumschlagen.
    Also werde ich folgendes testen: 2 Kerne für BS sperren, CUPS / Minecraft einen Kern und Fhem einen Kern. Dann mal schauen.

  • Ich würde hier noch einen kleinen Nachtrag leisten, der ein wenig in die Richtung zielt, die Archimedes vermutlich beschreiten will. Sich um Priritätenvergabe/Corepinning einzelner Tasks zu kümmern ist i.d.R. wenig zielführend und vermutlich ein Schuß nach hinten. Allerdings kann an das Kernelverhalten mit etablierten Mitteln doch ein wenig für einen gedachten Einsatzzweck optimieren - insofern man den Scheduler des Kernels vor dem Bauen entsprechend konfiguriert.
    Das folgende Bild zeigt die dafür zur Verfügung stehenden Optionen (nach Einspielen der RT Patches).

    Standardmäßig ist der Jessie (gilt vermutlich auch für Wheezy) Kernel als "Preemtible Kernel (Low-latency Desktop)" konfiguriert. Will man seinen Raspi nun eher als Server verwenden, bei dem es eher auf Durchsatz, als auf niedrige Latenzzeiten ankommt, dann bietet sich an, eher zur "No forced preemption (Server)" zu greifen.

    Daß eine Konfigurationsänderung etwas bewirkt, läßt sich zumindest über die Messung der Latenzzeiten zeigen:

    4.1.10-rt8-v7+ (inkl. patch-4.1.7-rt8.patch) Scheduler Modell: "No forced preemption (Server)"
    # Total: 008735268
    # Min Latencies: 00010
    # Avg Latencies: 00056
    # Max Latencies: 05174

    Meine gemessenen maximalen Latenzzeiten beim "Preemtible Kernel (Low-latency Desktop)" legen bei 1700µs, beim "Fully preemtible Kernel (RT)" lagen sie bei 170µs. Diese Messungen beziehen sich zwar auf die Version 4.1.8, und können so vielleicht nicht 100%ig übertragen werden, in der Summe zeigt sich jedoch, daß man eine gewisse "seriöse" Chance hat, seinen Kernel auf die zu bewältigenden Aufgaben zu trimmen.

    Achtung, nicht vergessen, nach einem apt-get update kann die ganze Arbeit wieder zum Teufel sein, wenn man nicht explizit unterbindet, daß der Kernel von der Aktualisierung ausgeschlossen wird.

    Noch ein Bauchgefühl meinerseits. Ich glaube nicht, daß es wirklich der Mühe Wert ist, sich hier vom Raspbian Mainstream abzukoppeln und einen eigenen Kernel zu bauen. Wenn die Leistung nicht reicht, dann sollte man die HW-Plattform überdenken. Der Scheduler ist vermutlich bei der Betrachtung der Gesamtperformanz nicht das Nadelöhr.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!