2.3.99-pre6-2 + page coloring auf Alpha

Florian Lohoff flo at rfc822.org
Sat Apr 15 12:35:07 CEST 2000


On Sat, Apr 15, 2000 at 03:45:47AM +0200, Jan-Benedict Glaw wrote:

> Superkurz: page coloring ist der Versuch, kernelseitig Speicherzugriffe so
> zu organisieren, daß immer möglichst viel von den Seitem im Cache gehalten
> werden kann. Wie man bei mir sieht, sollte dann aber auch etwas "mehr" Cache
> vorhanden sein. Ich denke mal, daß das bei mir nur nach hinten losgegangen
> ist, weil ich noch kein MB Cache hab;(

Afaik geht es hier weniger um den Cache als um den CPU Internen TLB 
(Translation Lookaside Buffer) der die Virtuellen in die Physikalischen
Addressen umsetzt (je ein entry pro Page, ~128-512 Entrys ja nach CPU).
Wenn die CPU versucht auf eine Page zuzugreifen die nicht im TLB "gecached"
ist wird ein sogenannter "Page Fault" ausgeloest der dann die entsprechende
Translation in den TLB laedt und die normale CPU execution weiterlaufen
laesst. Diese Page Faults sind ein problem nur in "Mittelgrossen" applikations
d.h. Applikations die gerade eben ueber die TLB grosse (D.h. z.b. >128 Pages)
hinausgehen. Bei kleinen Applikationen ist eh immer die ganze application
"Translated" - Bei grossen applications kommt man um Page Faults nicht 
drumherum. Es geht jetzt drum die Page faults zu minimieren d.h. den
Working set mit den meisten zugriffen nicht aus dem TLB zu flushen
bzw zu "Ueberschreiben".

Der Cache ist in diesem Fall nicht interessant weil er ueber die Physikalische
Addresse indiziert ist. (Zumindest bei i386)

> Nun, das hört sich an, als wär' da nicht viel von der Performance zu testen, 
> aber die Antwort auf die Frage "Paßt oder paßt der Code nicht in den Cache"
> kann über eine Größenordnung(!) in der Durchführung der Rechenarbeit ent-
> scheiden. Bei einigen Rechenleistungstests ist's sogar direkt erlaubt, den
> Algorithmus solange umzustellen, bis dieser (vollkommen handoptimiert) in den
> schnellen Cache paßt...

Das hat eher was mit Cache Lines zu tun. D.h. ich optimiere meine
Datenstrukturen so das wenn ich modifikationen vornehme immer moeglichst
nur EINE Cacheline betroffen ist um WENIG "Write Back" traffic zu erzeugen.
(Es koennen immer nur ganze Cache-Lines geschrieben bzw invalidiert werden)

> Das, was jetzt hier für Alpha (und nur für Alpha) angefangen worden ist, ist
> (auf neueren Maschinen) sicherlich ein Weg in die richtige Richtung, weil man
> durch den vergrößerten Aufwand beim memory management *deutlich* mehr aus 
> dem Rechner herausholen *kann*.

Page Coloring ist sehr umstritten - Diverse Ports probieren immer wieder
damit rum (PARisc z.b. auch) jedoch wird in 90% der faelle das relativ
schnell wieder fallengelassen.

Flo
-- 
Florian Lohoff		flo at rfc822.org		      	+49-subject-2-change
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."


-
Hinweise zur Benutzung dieser (und anderer Mailing-Listen) bitte beachten:
--> http://lug-owl.de/mailinglist_hints.html <--



More information about the Linux mailing list