[DE] prozesse/programme an eine cpu binden

[devil]

dual- und quadcore systeme sind weitverbreitet, doch oft langweilen sich alle kerne ausser dem ersten.
hier kommt taskset ins spiel. es bindet einen prozess/ein programm an einen kern.

Code: [Select]

taskset -c 0 <programm>
startet <programm> auf dem 1. core.

Code: [Select]

taskset -c 2,3
tut das gleiche auf dem 3. und 4. core.

Code: [Select]

taskset -p 123 -c 3weisst den laufenden prozess mit der pid 123 dem 4.kern zu.
nachzuprüfen mit top/htop.
um herauszufinden, welchen kern ein laufender prozess benutzt, reicht ein  

Code: [Select]

taskset -p 123

greetz
devil

[ab]

@devil

Danke!

gruß ab

[bluelupo]

Hi devil,
ein schöner Wikiartikel wäre das ;-)

[devil]

hab ich auch schon dran gedacht...

greetz
devil

[ralul]

dual- und quadcore systeme sind weitverbreitet, doch oft langweilen sich alle kerne ausser dem ersten. hier kommt taskset ins spiel. es bindet einen prozess/ein programm an einen kern.

Alternativ kann man den BrainFuckScheduler von Kolivas benutzen, denn er macht genau das automatisch, weil er eben nicht wie der Mainline CFScheduler davon ausgeht, wir alle hätten Supercomputer mit hunderten von Cores, für jeden Task einen. Deswegen schickt der BFS alles in eine Run-Queue, wie hier beschrieben http://ck.kolivas.org/patches/bfs/sched-BFS.txt

The reason for going back to a single runqueue design is that once multiple runqueues are introduced, per-CPU or otherwise, there will be complex interactions as each runqueue will be responsible for the scheduling latency and fairness of the tasks only on its own runqueue, and to achieve fairness and low latency across multiple CPUs, any advantage in throughput of having CPU local tasks causes other disadvantages.

Um den Hauptvorteil von Per-Core-Run-Queues auszugleichen, benutzt BFS Affinitäten von Prozessen zu Cores: Denn eine Wiederaufnahme eines Prozesses nach einem Kurzschlaf geht auf dem selben vorherigen Core schneller.

[autoandimat]

es bindet einen prozess/ein programm an einen kern. die kerne werden in diesem fall nicht von 0 ausgehend gezählt, sondern von 1

Irgendwie ist das seltsam. Bei mir geht das Zählen scheinbar bei Null los. :roll:
Ich teste es gerade auf einem Core 2 Duo E2200.
Wenn ich

Code: [Select]

taskset -c 0 <programm>
taskset -c 1 <programm>
eingebe funzt das und lässt sich auch in htop kontrollieren.
Beim Aufruf von

Code: [Select]

taskset -c 2 <programm>
erscheint die Meldung:

Code: [Select]

sched_setaffinity: Invalid argument
failed to set pid 0's affinity
Aber es funzt auf diese Weise mit 0 und 1. :wink:

[devil]

ehm, du hast natürlich recht, wie ich nach einem erneuten test feststellte.
thread und wiki korregiert.

greetz
devil