HT abschalten ohne Bios eingriff

Neogreen

Member
Hallo,

Ich versuche grad bei einen Atom Dedicated HT abzuschalten ohne Bios zugriff da sich dort OVH querstellt und eine KVM für 1 Monat gut 100Euro kosten würde.
Gäbe es da möglichkeiten über das OS zu deaktivieren?
 
Hallo,

Ich versuche grad bei einen Atom Dedicated HT abzuschalten ohne Bios zugriff da sich dort OVH querstellt und eine KVM für 1 Monat gut 100Euro kosten würde.
Gäbe es da möglichkeiten über das OS zu deaktivieren?

Du könntest einen Kernel ohne SMP (Mehrprozessorunterstützung) nutzen, bzw probieren ob der "nosmp" bootparameter bei heutigen Kernels noch funktioniert.

Über die Sinnhaftigkeit lässt sich aber wohl streiten...
 
Du kannst mit einem Python Script durchaus Bioseinstellungen modifizieren.

Müsstest nur das passende finden.

Ob es das für diese Funktion gibt kann ich nicht sagen.

Falsch ist jedenfalls das man das Bios NICHT aus einem laufenden OS verändern kann.

PS: Ein simples "noht" als Bootparameter geht nicht?
 
Die Frage war ja, ob man HT abschalten kann.

Ja. Das geht, z.B. über die angesprochenen Kernel-Parameter. Wenn das eine Single-Core-CPU ist, reicht das abschalten von SMP. Bei Multi-Core müsste man mal nachsehen, wie man nur das HT abschalten, das SMP aber laufen lassen kann. Linux benutzt das dann einfach nicht für sein Thread-Management.
 
Hardwareseitig lässt sich HT nur per BIOS (de)aktivieren.
Softwareseitig lassen sich die virtuellen HT-Cores, durch die entsprechenden Optionen beim Bauen des Kernels (oder durch das Setzen der genannten Bootparameter), gegenüber dem Kernel ausblenden/verstecken, sie bleiben aber hardwareseitig weiterhin aktiv, werden nur nicht mehr genutzt.

Zum Stromsparen hilft also nur das Deaktivieren per BIOS.
 
Es läuft darauf Ubuntu 12.04.1 LTS und es handelt sich hierbei um ein:
Intel Atom N2800 (2x 1,86Ghz + 2HT)

Es ist kein Singelcore sonder Dualcore, ich möchte HT abschalten da es die 2 vorhandenen Kerne zusätzlich belastet und für Voiceserver einfach unötig ist.
 
ich möchte HT abschalten da es die 2 vorhandenen Kerne zusätzlich belastet
Huh? HT ist eine Hardwarelösung in Form von 2 Taskqueues je physischem Core damit dieser, wenn ein Task warten muss, nicht Däumchen dreht sondern weiterarbeiten kann. Dadurch entsteht 5-30% _mehr_ Leistung, nicht weniger.
Es gibt -zumindest theoretisch- Möglichkeiten wenn es langsamer ist (da der L1 Cache der CPU recht klein ist), aber dies ist im Regularbetrieb nicht relevant.

für Voiceserver einfach unötig ist.
Ein Linux-System hat mehr als deine Voice-Server. Mehrere Threads/Prozesse auf mehrere Hardware-Threads auf zu teilen ist immer eine gute Idee.
 
Huh? HT ist eine Hardwarelösung in Form von 2 Taskqueues je physischem Core damit dieser, wenn ein Task warten muss, nicht Däumchen dreht sondern weiterarbeiten kann. Dadurch entsteht 5-30% _mehr_ Leistung, nicht weniger.
Es gibt -zumindest theoretisch- Möglichkeiten wenn es langsamer ist (da der L1 Cache der CPU recht klein ist), aber dies ist im Regularbetrieb nicht relevant.

So ist es im Idealfall - wie erklärst du dir dann, dass in diesem Fall hier die Pseudoabschaltung von HT geholfen hat, seltsame Phänomene in qemu-kvm auszumerzen?
http://serverfault.com/questions/40...limit-for-max-cpus-ubuntu-10-04/401955#401955

Vllt. lags an KVM?
 
So ist es im Idealfall - wie erklärst du dir dann, dass in diesem Fall hier die Pseudoabschaltung von HT geholfen hat
Ich bezweifele dass das der Grund des Threaderstellers war ;)

wie erklärst du dir dann, dass in diesem Fall hier die Pseudoabschaltung von HT geholfen hat, seltsame Phänomene in qemu-kvm auszumerzen?
Da danach laut TE auf Serverfault alles normal lief denke ich dass qemu aus irgendeinem Grund entschied beim Boot konstant die CPU ab zu geben und wieder zu brauchen was das System in die Knie bringt.

Ich bin mir nicht sicher aber ich bezweifele dass Hyperthreading dadurch nicht verwendet wurde, sondern die Anzahl an möglichen Recheneinheiten und somit die Anzahl an "Herumschieben" der KVM-Prozesse reduziert wurde.
 
wie erklärst du dir dann, dass in diesem Fall hier die Pseudoabschaltung von HT geholfen hat, seltsame Phänomene in qemu-kvm auszumerzen?
Da es offensichtlich ein (undokumentierter) Bug in qemu-kvm war, müsste man die beiden Versionen diffen und so den Bug rekonstruieren. Mit HT als Solchem hatte es jedenfalls nichts zu tun.

HT zu deaktivieren macht ausschliesslich Sinn, wenn man beispielsweise bei Embeddedsystemen auch die letzten zehntelchen an Strom einsparen muss, oder wenn es um kritische Infrastruktur mit erhöhten Sicherheitsrichtlinien geht (HT und Co können unter exotischen Bedingungen ein Sicherheitsrisiko darstellen). Letzteres sehe ich hier auf Grund der Fragestellung definitiv nicht und Ersteres halte ich für eher unwahrscheinlich. Somit tippe ich auf irgendeine dümmliche und/oder veraltete Empfehlung auf irgendeiner unwichtigen Website, welche zufällig per Google gefunden und völlig aus dem Zusammenhang gezogen wurde...
 
Das wurde mir von einen "Techniker" erzählt das es eben für Game/Voiceserver besser sei HT abzuschalten, da ich mich mit HT nicht richtig beschäftigt hatte ging ich nun davon aus.
 
Back
Top