Dynamisches Abschalten von Speicherkanälen: Möglich bzw. sinvoll? (Split aus HSW)

[AnarchX]

Wäre, wie schon einmal diskutiert, wohl aber eine gute Möglichkeit den Stromverbrauch weiter zu senken.
Oder sind die CPUs im mobilen Betrieb mittlerweile in der Lage einzelne Speicherkanäle abzuschalten?

[Gipsel]

Oder sind die CPUs im mobilen Betrieb mittlerweile in der Lage einzelne Speicherkanäle abzuschalten?
Dynamisch? Was passiert mit den Anwendungen, die dort im Speicher liegen?

[AnarchX]

Dynamisch? Was passiert mit den Anwendungen, die dort im Speicher liegen?
Ohne OS-Unterstützung dürfte sich das wohl in der Tat schwierig gestalten.

[Coda]

Dynamisch? Was passiert mit den Anwendungen, die dort im Speicher liegen?
Voher auf die anderne Riegel umkopieren? ;)

[ndrs]

Voher auf die anderne Riegel umkopieren? ;)
Ich glaub dabei geht mehr Energie verloren, als man durch das abschalten gewinnt.

[Gipsel]

Voher auf die anderne Riegel umkopieren? ;)
Ich glaub dabei geht mehr Energie verloren, als man durch das abschalten gewinnt.
Und wie AnarchX schon anmerkte, benötigt man OS-Support dafür. Denn wenn das OS den Speicher wild verteilt belegt (was ein Sicherheitsfeature ist! siehe ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization)), ist man nur am hin- und herkopieren. Es muß also gezielt z.B. nur in einer Hälfte bevorzugt alloziert werden. Außerdem darf der Adressraum nicht mehr per Interleaving über die Speichercontroller verteilt werden. Das Ganze wäre also auch mit einem gewissen Performanceverlust (zumindest für singlethreaded workloads) verbunden.

Alles in allem würde ich sagen, daß sich das kaum lohnt. Erfolgversprechender wäre es, bei geringer Last den Speichertakt (und den des Controllers) mitsamt Spannung runterfahren zu können.

[Coda]

Und wie AnarchX schon anmerkte, benötigt man OS-Support dafür.
Braucht man nicht. Hardware-Remapping tut's genauso.

Das war aber auch eher ein Scherz, denn das dürfte selbst mit hoher Bandbreite von der Latenz prohibitiv sein, selbst wenn man es nur in Ultra-Deep-Sleep macht.

Denn wenn das OS den Speicher wild verteilt belegt (was ein Sicherheitsfeature ist! siehe ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization)), ist man nur am hin- und herkopieren.
Jetzt hast du aber gerade einen Bock geschossen Gipsel. ASLR bezieht sich natürlich auf den virtuellen Adressraum der Applikation, nicht auf den physikalischen des Prozessors.

[Gipsel]

Braucht man nicht. Hardware-Remapping tut's genauso.Du schlägst also vor, daß die CPU noch eine Zusatzebene der Virtualisierung des Speichers einzieht (bisher physisch => jetzt wirklich physisch) oder alternativ eigenmächtig die Pagetables des OS verändert? Und zusätzlich gleich noch notfalls die Auslagerung auf die Platte ohne Mitwirkung des OS initiiert? :|
Das war aber auch eher ein Scherz, denn das dürfte selbst mit hoher Bandbreite von der Latenz prohibitiv sein, selbst wenn man es nur in Ultra-Deep-Sleep macht.

Jetzt hast du aber gerade einen Bock geschossen Gipsel. ASLR bezieht sich natürlich auf den virtuellen Adressraum der Applikation, nicht auf den physikalischen des Prozessors.Letzteres stimmt natürlich. :redface:

Ändert aber auch nichts daran, daß ohne OS-Mithilfe immer Speicher über alle Controller verteilt in Benutzung sein dürfte und damit - wie Du schon gesagt hast - aus Gründen der Latenz (und Energiekosten) das allerhöchstens in einer Art Suspend-to-RAM-Mode einsetzbar sein könnte (man behält nur Daten im RAM an einem Speichercontroller/einem Speicherriegel für das schnelle Aufwachen aktiv, der Rest wird notfalls auf SSD ausgelagert). Aber ob sich der Aufwand lohnt, um den Energieverbrauch im STR-Mode ein wenig zu drücken, wage ich dann doch zu bezweifeln.

[Coda]

Du schlägst also vor, daß die CPU noch eine Zusatzebene der Virtualisierung des Speichers einzieht (bisher physisch => jetzt wirklich physisch) oder alternativ eigenmächtig die Pagetables des OS verändert? Und zusätzlich gleich noch notfalls die Auslagerung auf die Platte ohne Mitwirkung des OS initiiert? :|
Letzteres stimmt natürlich. :redface:
Würde alles im Speichercontroller gemacht (der muss sowieso schon alternierend auf die Bänke zugreifen etc.). Für den Cache wären die physikalischen Adressen völlig transparent.

Das OS müsste halt immer noch dafür sorgen, dass es dann nur die untere Hälfte des physikalischen Speicherraums benutzt bla bla. Alles Blödsinn.

[Skysnake]

Dynamisch? Was passiert mit den Anwendungen, die dort im Speicher liegen?
Wird von Trinity, oder wars der Nachfolger? von AMD aber auch unterstützt.

Hab mich jetzt da noch nicht näher mit beschäftigt, aber es wird wohl mehr oder weniger darauf raus laufen, das man einfach die clock abschaltet, und/oder die Taktrate des Interfaces stark reduziert. Der DRAM-Riegel ist ja apriori nicht auf eine Clock angewiesen, außer für den Refresh.

[Gipsel]

Hab mich jetzt da noch nicht näher mit beschäftigt, aber es wird wohl mehr oder weniger darauf raus laufen, das man einfach die clock abschaltet, und/oder die Taktrate des Interfaces stark reduziert. Der DRAM-Riegel ist ja apriori nicht auf eine Clock angewiesen, außer für den Refresh.
Sowas habe ich oben ja schon geschrieben. ;)

[Skysnake]

ich wollts nur nochmal klar stellen, das es möglich ist da einiges zu machen ;)

[GloomY]

Jungs und Mädels: Noch nie was von partitial self-refresh (PSR) bei mobile-DRAM gehört? Das kann man genau dafür verwenden, nur eine gewissen Teil eines Ranks zu refreshen. Die meiste Energie geht nämlich beim Auslesen und wiederbeschreiben der Zellen - also beim Refresh drauf. Das bischen Energie für z.B. das Taktsignal fällt da nicht wirklich ins Gewicht. Auch weil das DRAM beim Self-Refresh den Refresh alleine und ohne Befehl des Speichercontrollers macht, braucht es das Taktsignal als Zeitgeber.