Ich habe an mehreren Stellen gelesen, dass der Standard-Scheduler von Linux @ ishyperthreading aware auf Multi-Core-Rechnern, dh wenn Sie einen Rechner mit 2 realen Kernen (4 HT) haben, werden nicht zwei ausgelastete Threads auf logischen Kernen so eingeplant, dass beide auf denselben physischen Kernen ausgeführt werden (was dazu führen würde) zu 2x Leistungskosten in vielen Fällen).

Aber wenn ich rennestress -c 2 (erzeugt zwei Threads, die auf 100% CPU ausgeführt werden) auf meinem Intel i5-2520M,es plant oft (und behält)die zwei Threads auf den HT-Kernen 1 und 2, die demselben physischen Kern zugeordnet sind. Auch wenn das System sonst im Leerlauf ist.

Das passiert auch mit echten Programmen (ich benutzestress hier, weil es einfach zu reproduzieren ist), und wenn das passiert, dauert mein Programm verständlicherweise doppelt so lange. Affinität manuell einstellen mittaskset behebt das für mein Programm, aber ich würde erwarten, dass ein HT-fähiger Scheduler das von sich aus richtig macht.

Sie finden das HT-> physischer Kern Zuordnung mitegrep "processor|physical id|core id" /proc/cpuinfo | sed 's/^processor/\nprocessor/g'.

Also meine Frage ist: Warum legt der Scheduler meine Threads hier auf denselben physischen Kern?

Anmerkungen

Diese Frage ist sehr ähnlich zu diesemandere Frag, die Antworten auf die sagen, dassLinux hat einen ausgeklügelten Thread-Scheduler, der HT-fähig ist. Wie oben beschrieben, kann ich diese Tatsache nicht beobachten (überprüfen Sie selbst mitstress -c) und möchte wissen warum.Ich weiß, dass ich die Prozessoraffinität für meine Programme manuell einstellen kann, z. mit demtaskset tool oder mit demsched_setaffinity Funktion. Dies ist nicht das, wonach ich suche. Ich würde erwarten, dass der Scheduler von sich aus weiß, dass es keine gute Idee ist, zwei ausgelastete Threads einem physischen Kern zuzuordnen und einen physischen Kern vollständig leer zu lasse Ich bin mir bewusst, dass essome situations, in dem Sie es vorziehen würden, Threads auf demselben physischen Kern zu planen und den anderen Kern frei zu lassen, aber es erscheint unsinnig, dass der Scheduler das in etwa 1/4 der Fälle tun würde. Es scheint mir, dass die von ihm ausgewählten HT-Kerne völlig zufällig sind, oder vielleicht diejenigen HT-Kerne, die zum Zeitpunkt der Planung die geringste Aktivität aufwiesen, aber das wäre nicht sehr hyperthreading-bewusst, wenn man bedenkt, wie deutlich Programme mit den Merkmalen von @ sinstress Profitieren Sie von der Ausführung auf separaten physischen Kernen.