Siduction Forum > Scripting & Kernelhacking

[DE] prozesse/programme an eine cpu binden

(1/2) > >>

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: ---taskset -c 0 <programm>
--- End code ---

startet <programm> auf dem 1. core.
--- Code: ---taskset -c 2,3
--- End code ---

tut das gleiche auf dem 3. und 4. core.

--- Code: ---taskset -p 123 -c 3
--- End code ---
weisst 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: ---taskset -p 123
--- End code ---


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:

--- Quote from: 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.
--- End quote ---
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

--- Quote from: C.Kolivas ---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.
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page