Kernel 2.4.29 und A64 Unterstützung

Wuschl

Vice Admiral Special
Mitglied seit
11.11.2001
Beiträge
963
Renomée
1
Standort
Himberg/Wien
Hallo!

Ich hätte gerna mal ein Problem, und zwar lässt sich bei meiner Slack 10.1 final der 2.4.29er Kernel nicht mit Athlon64 Unterstützung kompilieren, sondern speichert immer mit K7-Athlon Unterstützung ab und kompiliert entsprechend. Bei 10.1 RC1 gings noch *noahnung*

Und damit ihr meine Beweggründe versteht:
Im 32 bit Ati - Treiber fehlt die Unterstützung für den A64 Agp Controller und ich muß somit den Umweg über das externe Gart Modul gehen und das kostet Frames.

Spricht mein Kernel 64 Bit, so komme ich in den Genuß eines internen Gart Moduls.

Mache ich was falsch oder wie????

Gruß Wuschl
 
hmmm warum backst du dir nicht einfach einen 2.6er Kernel und versuchst es mit dem?
 
Also willst du einen 2.4er mit A64 GART Treiber oder einen 64Bit 2.4er Kernel? Letzteres ist bei Slack definitiv nur schwierig möglich.
 
Original geschrieben von Diablo
hmmm warum backst du dir nicht einfach einen 2.6er Kernel und versuchst es mit dem?

Werd ich mal machen....

Original geschrieben von i_hasser

Also willst du einen 2.4er mit A64 GART Treiber oder einen 64Bit 2.4er Kernel? Letzteres ist bei Slack definitiv nur schwierig möglich.

Ich wollte einen 2.4er mit 64Bit Unterstützung um das interne Gart Modul des Ati Treibers nutzen zu können.

Was ich nicht verstehe: Mit Slack 10.1 RC1 gings ohne irgendwelche Probs. Aber scheinbar muß ich mich an dan 2.6er halten...

Gruß Wuschl
 
Also willst du einen AMD64 Kernel?

Dafür brauchst du einen GCC der in der Lage ist per Crosscompiling auch AMD64 Progs zu erzeugen, sonst kann das nicht gehen.

Sauber wird das in keinem Fall, da Slackware eigentlich eine reine i386 Distri ist... leider.
 
Hab's heute nochmal mit der 10.1 RC1 (die Version die den Kernel schon mal für "Hammer" kompiliert hat) probiert, und es ging nicht.... *noahnung* Komisch...

Na ich werde wieder mal sauber 32bittig installieren, schließlich will ich damit ja auch noch was arbeiten und nicht nur herumexperimentieren.

Gruß Wuschl
 
Original geschrieben von i_hasser
Also willst du einen AMD64 Kernel?

Dafür brauchst du einen GCC der in der Lage ist per Crosscompiling auch AMD64 Progs zu erzeugen, sonst kann das nicht gehen.

Nicht nur das, die binutils müssen das auch können. Linker und Assembler gehören nämlich mitnichten zum gcc. ;)
 
Naja wie auch immer, es macht aber herzlich wenig Sinn einen AMD64 Kernel für ein IA32 OS zu benutzen, da wirst du sehr wahrscheinlich ein gutes Stück Performance verlieren, weil kein Prog nativ läuft.
 
Wieso langsamer, und wieso nicht nativ? Bei x86_64 wird nichts emuliert. Das, was dazu kommt, sind die 32bit-Systemaufrufe, die für 32bit-Anwendungen noch zusätzlich zur Verfügung gestellt werden müssen. Wo soll da so viel Performance verloren gehen? *noahnung*
 
Genau da. Es ist schlicht unnötige Arbeit die man mit einem IA32 Kernel nicht hat.
 
Ich sehe da nicht, wo die Performance drauf gehen sollte. Wir können das aber gerne an Hand von Benchmarks klären. :D
 
Ich hab hier kein AMD64 Linux laufen, da Slackware eben eine IA32 Distri ist... leider :(.

Der direkte Vergleich ist auch nicht so ganz einfach, man müsste ein Prog nehmen, das viele OS Aufrufe generiert. Also ein einfacher Whetstone oder Dhrystone reicht da nicht aus.

Denkbar wäre irgendein schönes GUI Prog. Der Vergleich wird aber auch wegen AMD64 vs. IA32 nicht so einfach, den IA32 Code kann man auch nicht so ohne weiteres übersetzen, weil in AMD64 ja kein RegRenaming zur Verfügung steht (wäre schwierig bei 16 Regs).
 
Original geschrieben von i_hasser
Ich hab hier kein AMD64 Linux laufen, da Slackware eben eine IA32 Distri ist... leider :(.

Gentoo ;D

Ich kanns also testen.


Der direkte Vergleich ist auch nicht so ganz einfach, man müsste ein Prog nehmen, das viele OS Aufrufe generiert. Also ein einfacher Whetstone oder Dhrystone reicht da nicht aus.

Och, mir fallen da gleich eine ganze Menge ein, die man dafür ran zeihen kann:

* Audio und Video encoden (oggenc, lame, mencoder...)
* povray
* compression/decompression (gzip, bzip2)


Der Vergleich wird aber auch wegen AMD64 vs. IA32 nicht so einfach, den IA32 Code kann man auch nicht so ohne weiteres übersetzen, weil in AMD64 ja kein RegRenaming zur Verfügung steht (wäre schwierig bei 16 Regs).

Welches RegRenaming meinst du, das was der Proz macht oder das vom Compiler? Du liegst hier aber bei beiden falsch.
Des weiteren weiß ich auch noch nicht so richtig, was du damit meinst, den IA32 Code nicht so ohne weiteres übersetzen zu können. ???
 
Original geschrieben von PuckPoltergeist
* Audio und Video encoden (oggenc, lame, mencoder...)
* povray
* compression/decompression (gzip, bzip2)

Das ist Quatsch, nix davon erzeugt ordentlich Aufrufe an das OS!

Welches RegRenaming meinst du, das was der Proz macht oder das vom Compiler? Du liegst hier aber bei beiden falsch.
Des weiteren weiß ich auch noch nicht so richtig, was du damit meinst, den IA32 Code nicht so ohne weiteres übersetzen zu können. ???

Nein, du liegst falsch. 1. nennt sich das was der Compiler macht nicht regrenaming, und 2. macht der A64 auf 16 Regs kein Renaming, wäre ein bisschen kompliziert und außerdem müsste man die Registerzahl für's Renaming deutlich erhöhen da sich selbiges eben auf 16 und nichtmehr 6 Regs bezieht.

Also entweder wird das Renaming sehr stark eingeschränkt bezüglich der Zahl der Schattenregs, oder komplett aufgegeben - was meines Wissens beim A64 der Fall ist.
 
Original geschrieben von i_hasser
Das ist Quatsch, nix davon erzeugt ordentlich Aufrufe an das OS!

Was sind bei dir ordentliche Aufrufe an das OS? Du musst dabei immer davon ausgehen, dass das noch messbar ist. Außerdem, bzip2 liest die zu komprimierende Datei zeichenweise ein. Für mich ist das schon einiges an Aufrufen.

PS: Um das zu testen, würden aber schon zwei Prozesse reichen, die sich permenant irgendwelche Nachrichten zuschicken, und darauf nicht wirklich arbeiten. Damit geht praktisch die gesamte Bearbeitungszeit nur für die syscalls bzw. die Prozessumschaltung drauf.


Nein, du liegst falsch. 1. nennt sich das was der Compiler macht nicht regrenaming, und

aus dem gcc-manual
-frename-registers
Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a “home register”.

Zumindest die gcc-Entwickler nennen es so.


2. macht der A64 auf 16 Regs kein Renaming, wäre ein bisschen kompliziert und außerdem müsste man die Registerzahl für's Renaming deutlich erhöhen da sich selbiges eben auf 16 und nichtmehr 6 Regs bezieht.

Also entweder wird das Renaming sehr stark eingeschränkt bezüglich der Zahl der Schattenregs, oder komplett aufgegeben - was meines Wissens beim A64 der Fall ist.

Dein Wissen ist scheinbar falsch. Der K8 macht das soger recht intensiv. ;)

http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html
 
Zuletzt bearbeitet:
Zurück
Oben Unten