Gentoo-spezifische Optimierungen bzw. Tipps
- Ersteller Sensei21
- Erstellt am
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
freak01 schrieb:
könntest du das mal genauer erklären? also /usr/portage ist bei dir ausgelagert oder /var/tmp/portage* oder was genau? und warum wird das ganze denn komprimiert? bedeutet das nicht kleinere speicherplatuz für langsameren zugriff (da ja entpackt werden muss). Und wie aktiviere ich sqlite-backend und was bringt das? (sqlite useflag ist gesetzt)
da du ja dein system wohl gerne optimierst: hast du schon Prelinking genutzt? soll ja gerade bei kde was bringen. wenn ja: wie sind deine erfahrungen?
*dieser ordner sollte wohl am besten auf ein ramfs gelegt werden
- Registriert
- März 2002
- Beiträge
- 3.311
zu 1) /usr/portage ist auf einer separaten Partition mit reiser4 mit cryptcompress (mit transparenter gzip-Komprimierung), da es in der Vergangenheit hauptsächtlich um eine schnelle Abfrage bzw. Reaktionszeit der Abhängigkeiten ging, hab ich durch experimentieren rausgefunden, dass der besagte Partitionstyp beim syncen (emerge --sync bzw. paludis -s) und emerge foo am schnellsten abschnitt.
Ein weiterer Vorteil war die sehr platzsparende Speicherung der Daten (besonders auf meinem Laptop)
Voraussetzung ist natürlich eine CPU, die das ganze schnell genug verarbeiten kann
optimal für etwas langsamere System ist die lzo-Kompression, die "Echtzeit"komprimierung anbietet und nicht spürbar langsamer ist als ohne Komprimierung aber dennoch recht gut den portage-Baum komprimiert
das Entpacken macht das Dateisystem im Arbeitsspeicher und ist für das System bzw. die Programme nicht bemerkbar, das läuft alles durch die reiser4-eigene "Plugin"-Architektur im Hintergrund ab
zu 2) /var/tmp/portage
das ist bei mir in einem tmpfs abgelegt, da so der Kompiliervorgang generell etwas schneller als auf der Platte von statten geht
(ich hab gern Kontrolle über mein System und lade und entlade das jeweils immer manuall)
zu 3) das sqlite-backend musst du explizit über /etc/portage/modules
"freischalten", zuvor muss aber pysqlite installiert sein, in /etc/make.conf bei FEATURES="metadata-transfer" eingetragen sein. Danach den cache in /var/cache/edb/dep/* löschen (vorher ein backup der daten erstellen!), nun mit
den Abhängigkeits-cache neu erstellen, damit werden die Daten nicht einzeln Stück für Stück im Ordner abgelegt (im Grunde also ein "kleiner" Portage-Baum, sondern alles in einer recht flotten sqlite-Datenbank abgelegt; es würde wohl auch über mysql-gehen, die schneller sein sollen, hierfür gibt es aber keine Anleitung)
Quelle: gentoo-wiki: Portage SQLite Cache
zu 4) prelinking nutze ich seit längerer Zeit nicht mehr,
ich kenne gerade nicht den genauen Grund, aber soviel ich weiß wird das ganze durch die hardened toolchain überflüssig (-Wl,-z,now ; ...) :
LDFLAGS="${LDFLAGS} -Wl,--as-needed"
CFLAGS="${CFLAGS} -mno-align-stringops -minline-stringops-dynamically"
(die CFLAGS haben natürlich nichts damit zu tun, verhelfen aber zu einem hübschen Geschwindigkeitsschub bei der Laufzeit und beim Start)
Ein weiterer Vorteil war die sehr platzsparende Speicherung der Daten (besonders auf meinem Laptop)
Voraussetzung ist natürlich eine CPU, die das ganze schnell genug verarbeiten kann
optimal für etwas langsamere System ist die lzo-Kompression, die "Echtzeit"komprimierung anbietet und nicht spürbar langsamer ist als ohne Komprimierung aber dennoch recht gut den portage-Baum komprimiert
das Entpacken macht das Dateisystem im Arbeitsspeicher und ist für das System bzw. die Programme nicht bemerkbar, das läuft alles durch die reiser4-eigene "Plugin"-Architektur im Hintergrund ab
zu 2) /var/tmp/portage
das ist bei mir in einem tmpfs abgelegt, da so der Kompiliervorgang generell etwas schneller als auf der Platte von statten geht
Code:
mount -t tmpfs tmpfs -o size=8450000000 /var/tmp/portagezu 3) das sqlite-backend musst du explizit über /etc/portage/modules
Code:
portdbapi.auxdbmodule = cache.sqlite.database
Code:
emerge --metadataQuelle: gentoo-wiki: Portage SQLite Cache
zu 4) prelinking nutze ich seit längerer Zeit nicht mehr,
ich kenne gerade nicht den genauen Grund, aber soviel ich weiß wird das ganze durch die hardened toolchain überflüssig (-Wl,-z,now ; ...) :
LDFLAGS="${LDFLAGS} -Wl,--as-needed"
CFLAGS="${CFLAGS} -mno-align-stringops -minline-stringops-dynamically"
(die CFLAGS haben natürlich nichts damit zu tun, verhelfen aber zu einem hübschen Geschwindigkeitsschub bei der Laufzeit und beim Start)
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
also das werde ich auch mal ausprobieren wobei ich keine kompression brauche. das einzige was das verzeichnis so fett macht ist ja der /usr/portage/distfiles ordner und wenn man binaries hat dann macht auch noch /usr/portage/packages was aus. die distfiles könnte man aber auch eigentlich löschen da die meistens nicht mehr gebraucht werden.
/var/tmp/portage habe ich wie erwähnt auch ausgelagert habe aber noch zusätzlich die inodes vergrößert mit -o nr_inodes=2M. weiterhin habe ich noch ccache an (was natürlich auch speicher braucht). hier mal meine make.conf features:
damit das geht muss man halt vorher ccache emergen.
parallel-fetch ist sehr praktisch wenn man viel auf einmal emergt. meta packages z.b.
userfetch bringt wohl nicht wirklich was
buildpkg habe ich drin wenn was total schief läuft damit ist kde und der komplette xserver in 5-10 min wieder da. das kann manchmal praktischer sein als ein stage4 tarball den ich mir auch regelmäßig anlege.
EDIT
wieso hast du eigentlich 8 GB für deine ramdisk reserviert? schadet ja nicht aber ist imho doch "leicht" übertrieben.
hm.. das mit dem sqlite hat bei mir irgendwie nichts gebracht. synccen dauert auch nicht kürzer (eher länger). emerge habe ich noch nicht getestet. das ganze ist auf einer verschlüsselten ext4 partition. kann das jetzt nicht weiter testen weil ich vom server gebannt wurde und ein ip wechsel ja auch fies wäre.
zu deinen C(XX)FLAGS: (LDFLAGS habe ich gar keine...)
haben diese irgendwelche nachteile (also wie z.b. -O3 oder -fomit-framepointers...)? kann ich die bedenkenlos für meinen i7 und meinen alten dual core (glaube E6600) verwenden und einen geschwindigkeitsvorteil erwarten? ein system ist hardened und das andere normal. und bitte verweise jetzt nicht auf die gcc documentation ;-)
/var/tmp/portage habe ich wie erwähnt auch ausgelagert habe aber noch zusätzlich die inodes vergrößert mit -o nr_inodes=2M. weiterhin habe ich noch ccache an (was natürlich auch speicher braucht). hier mal meine make.conf features:
Code:
FEATURES="parallel-fetch userfetch ccache buildpkg"
CCACHE_SIZE="2G"
CCACHE_DIR="/var/tmp/ccache"damit das geht muss man halt vorher ccache emergen.
parallel-fetch ist sehr praktisch wenn man viel auf einmal emergt. meta packages z.b.
userfetch bringt wohl nicht wirklich was
buildpkg habe ich drin wenn was total schief läuft damit ist kde und der komplette xserver in 5-10 min wieder da. das kann manchmal praktischer sein als ein stage4 tarball den ich mir auch regelmäßig anlege.
EDIT
wieso hast du eigentlich 8 GB für deine ramdisk reserviert? schadet ja nicht aber ist imho doch "leicht" übertrieben.
Ergänzung ()
hm.. das mit dem sqlite hat bei mir irgendwie nichts gebracht. synccen dauert auch nicht kürzer (eher länger). emerge habe ich noch nicht getestet. das ganze ist auf einer verschlüsselten ext4 partition. kann das jetzt nicht weiter testen weil ich vom server gebannt wurde und ein ip wechsel ja auch fies wäre.
zu deinen C(XX)FLAGS: (LDFLAGS habe ich gar keine...)
haben diese irgendwelche nachteile (also wie z.b. -O3 oder -fomit-framepointers...)? kann ich die bedenkenlos für meinen i7 und meinen alten dual core (glaube E6600) verwenden und einen geschwindigkeitsvorteil erwarten? ein system ist hardened und das andere normal. und bitte verweise jetzt nicht auf die gcc documentation ;-)
Zuletzt bearbeitet:
- Registriert
- März 2002
- Beiträge
- 3.311
die 8GB waren früher mal sinnvoll, als man openoffice noch vollständig im speicher kompilieren konnte jetzt wird das so groß, dass er ständig swappen muss, bei chromium von google oder boost sind auch schnell mal 3 GB belegt. Das ist ja nicht schlimm, da der Speicher gleich danach wieder frei ist 
das sqlite-backend ist nur beim emergen und beim erstellen des caches gut, beim syncen bringt das nicht wirklich viel:
stell mal folgendes in /etc/make.conf
dann kannst du etwas öfters syncen, wenn es mal nötig ist
ja:
-O3 ist unsicher, weil es die Genauigkeit opfert (z.B. mit -ffast-math); deswegen hab ich in manchen Fällen so gut wie alle Flags von -O3 aktiviert, die unsicheren sind bei mir jedoch weggelassen bzw. werden aufgehoben z.B. via CFLAGS="${CFLAGS} -fno-strict-overflow -fno-delete-null-pointer-checks"
-fomit-framepointer ist standardmäßig bei 64bit aktiviert und bei 32bit hindert es beim debuggen, wenn man mal ein problem verfolgen muss
hier mal eine Liste der CFLAGS/CXXFLAGS, die ich soweit getestet habe und auch mit dem ganzen System laufen (in der gcc doku nachzulesen !):
<-- hardened
<-- geht mit glibc nicht (und 1-2 anderen ebuilds nicht)
das heißt jetzt nicht, dass automatisch alles viel schneller damit läuft, es sind nur die flags, die nicht gleich das ganze unbrauchbar machen ...
ob und wieviel du davon nutzt ist deine Sache
zu stage4 und buildpackage:
geniale Sache
beides hat mir in diversen Fällen schon aus der "Patsche" geholfen
das sqlite-backend ist nur beim emergen und beim erstellen des caches gut, beim syncen bringt das nicht wirklich viel:
stell mal folgendes in /etc/make.conf
Code:
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"ja:
-O3 ist unsicher, weil es die Genauigkeit opfert (z.B. mit -ffast-math); deswegen hab ich in manchen Fällen so gut wie alle Flags von -O3 aktiviert, die unsicheren sind bei mir jedoch weggelassen bzw. werden aufgehoben z.B. via CFLAGS="${CFLAGS} -fno-strict-overflow -fno-delete-null-pointer-checks"
-fomit-framepointer ist standardmäßig bei 64bit aktiviert und bei 32bit hindert es beim debuggen, wenn man mal ein problem verfolgen muss
hier mal eine Liste der CFLAGS/CXXFLAGS, die ich soweit getestet habe und auch mit dem ganzen System laufen (in der gcc doku nachzulesen !):
(whois und ein paar andere ebuilds werden glaub ich mit -combine nicht kompiliert)
<-- gcc 4.4 flags (einige ebuilds könnten damit evtl. nicht kompiliert werden, z.B. libcanberra)
Code:
LDFLAGS="-Wl,-O1 -Wl,--hash-style=both -Wl,--sort-common -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed"
Code:
LDFLAGS="${LDFLAGS} -Wl,-z,now -Wl,-z,relro"
Code:
LDFLAGS="${LDFLAGS} -Wl,--relax"das heißt jetzt nicht, dass automatisch alles viel schneller damit läuft, es sind nur die flags, die nicht gleich das ganze unbrauchbar machen ...
ob und wieviel du davon nutzt ist deine Sache
zu stage4 und buildpackage:
geniale Sache
beides hat mir in diversen Fällen schon aus der "Patsche" geholfen
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
habe bis jetzt nur march=native -O2 und -pipe drin. meinst du also das
das system verbessert ohne irgendwas "totzuoptimieren" oder ein "ricer" zu sein? sind diese einstellungen also noch verantwortungsbewusst/in vertretbaren rahmen?
das sqlite lass ich jetzt erstmal an. stören tut es ja nicht wirklich.
EDIT
ok du hast deinen beitrag ja noch ordentlich erweitert. werde das glaube ich mal erst verarbeiten müssen falls überhaupt möglich. wahrscheinlich bleibe ich aber bei den normalen flags und versuche auf meinem nicht hardened system lieber mal das prelinking aus. eh sei denn du empfiehlst das ein oder andere flag universell. du scheinst ja mehr erfahrung zu haben als ich. mit gcc 4.4 hab ich auch schon rumgewerkelt aber mit hardened gentoo und kde4 das war echt zum kotzen. pausenlos irgendwelche blocks oder compiler errors. sowas mache ich nicht mehr.
übrigens sehr lustig finde ich folgendes:
Quelle: http://www.gentoo.org/doc/de/gcc-optimization.xml
obwohl du diese flags nicht emfpohlen hast: ich glaube das mit den flags ist mehr eine glaubensfrage als eine reale verbesserung. kann das sein? naja wenn ich mal zeit und lust habe teste ich die von dir geposteten flags. (und zwar alle mit copy & paste.) es spricht für dich das du keines dieser flags gepostet hast.
Code:
CFLAGS="-march=native -O2 -pipe -mno-align-stringops -minline-stringops-dynamically
-fno-strict-overflow -fno-delete-null-pointer-checks"
CXXFLAGS="$CFLAGS"das system verbessert ohne irgendwas "totzuoptimieren" oder ein "ricer" zu sein? sind diese einstellungen also noch verantwortungsbewusst/in vertretbaren rahmen?
das sqlite lass ich jetzt erstmal an. stören tut es ja nicht wirklich.
EDIT
ok du hast deinen beitrag ja noch ordentlich erweitert. werde das glaube ich mal erst verarbeiten müssen falls überhaupt möglich. wahrscheinlich bleibe ich aber bei den normalen flags und versuche auf meinem nicht hardened system lieber mal das prelinking aus. eh sei denn du empfiehlst das ein oder andere flag universell. du scheinst ja mehr erfahrung zu haben als ich. mit gcc 4.4 hab ich auch schon rumgewerkelt aber mit hardened gentoo und kde4 das war echt zum kotzen. pausenlos irgendwelche blocks oder compiler errors. sowas mache ich nicht mehr.
übrigens sehr lustig finde ich folgendes:
chinamaschiene schrieb:
freak01 schrieb:
Ergänzung ()
Quelle: http://www.gentoo.org/doc/de/gcc-optimization.xml
obwohl du diese flags nicht emfpohlen hast: ich glaube das mit den flags ist mehr eine glaubensfrage als eine reale verbesserung. kann das sein? naja wenn ich mal zeit und lust habe teste ich die von dir geposteten flags. (und zwar alle mit copy & paste.) es spricht für dich das du keines dieser flags gepostet hast.
Zuletzt bearbeitet:
- Registriert
- März 2002
- Beiträge
- 3.311
ja, also diese flags sollten recht sicher sein, wobei -fno-strict-overflow -fno-delete-null-pointer-checks schon durch die hardened toolchain / gcc abgedeckt sind, wenn du diese von http://forums.gentoo.org/viewtopic-t-790110.html (das gcc im portage-Baum dürfte das mittlerweile auch haben glaub ich zumindest) hast, dadurch ergibt sich ein Leistungsverlust von ca. 3-5% aber mir ist es wert, wenn dadurch weniger Bugs, etc. getriggert werden bzw. entstehen
durch das sqlite ist das erstellen der Datenbank von Portage aber schon schneller geworden, oder ? du wirst schon merken, dass bei emergen der Suchvorgang portage mit dem kompilieren beginnt sich signifikant verkürzt
ich deswegne auf die doku verwiesen, weil ich keine lust habe, jede einzelne jetzt hier durchzukauen und zu erklären was und wie es den code verbessert bzw. optimiert
durch gute flags kann man schon gut und gerne 20% oder mehr aus dem code rausholen und ein hardware-mäßig schnelleres system an leistung übertrumpfen
zu -funroll-loops -funroll-all-loops (ist glaub ich von der bedeutung im gcc sogar das gleiche), werden alle "schleifen" ausgerollt und gewissermaßen im programm festgegossen, es wird also jede anweisung explizit ausgeschrieben: http://en.wikipedia.org/wiki/Loop_unwinding
das sind schon reale verbesserungen, du musst nur die anwendungsfälle dafür erfüllen, bei denen man dies auch spürbar merkt !
also ich meld mich dann mal ab
over and out
durch das sqlite ist das erstellen der Datenbank von Portage aber schon schneller geworden, oder ? du wirst schon merken, dass bei emergen der Suchvorgang portage mit dem kompilieren beginnt sich signifikant verkürzt
ich deswegne auf die doku verwiesen, weil ich keine lust habe, jede einzelne jetzt hier durchzukauen und zu erklären was und wie es den code verbessert bzw. optimiert
durch gute flags kann man schon gut und gerne 20% oder mehr aus dem code rausholen und ein hardware-mäßig schnelleres system an leistung übertrumpfen
zu -funroll-loops -funroll-all-loops (ist glaub ich von der bedeutung im gcc sogar das gleiche), werden alle "schleifen" ausgerollt und gewissermaßen im programm festgegossen, es wird also jede anweisung explizit ausgeschrieben: http://en.wikipedia.org/wiki/Loop_unwinding
das sind schon reale verbesserungen, du musst nur die anwendungsfälle dafür erfüllen, bei denen man dies auch spürbar merkt !
also ich meld mich dann mal ab
over and out
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
da es hier um gentoo-tips geht habe ich eine frage:
es geht um die deutsche lokalisierung. die tutorials und anleitungen die man auf gentoo.org und diversen foren findet habe ich schon alle durch. ich habe auch schon sehr lange sehr viel rumexperimentiert es hat aber alles nicht funktioniert.
zum problem: in der konsole (nicht in kde!) kriege ich manchmal diesen nervigen fragezeichen-char wenn ich die backspace taste nutze. erzeugen kann ich das durch eingabe eines umlauts wie z.b. ö den ich dann mit backspace lösche. bestätige ich die eingabe taucht dieses fragezeichen auf. so kann ich z.b. auch den eingabe prompt löschen. ein weiteres backspace problem gibt es z.b. bei fdisk. dort kann ich die eingabe nicht löschen sondern er erzeugt mir entweder komische zeichen oder er löscht gar nicht.
ich habe es inzwischen aufgegeben aber vielleicht habe ich ja etwas ganz einfaches übersehen. hier mal relevante teile meiner config files. die auskommentierte dinge (und auch mehr) habe ich schon alle durchprobiert.
/etc/conf.d/consolefont
/etc/rc.conf
/etc/conf.d/keymaps
/etc/locale.gen
diese Lokals wurden mit locale-gen generiert. (und beim emergen von glibc automatisch auch noch über 400 andere, weiß nicht ob das nötig ist/war)
/etc/env.d/02locale
nach diversen versuchen wurde immer env-update und source /etc/profile ausgeführt
eine lösung würde mich freuen auch wenn ich mich inzwischen schon fast daran gewöhnt habe.
weiterhin habe ich auch im make menuconfig menu des kernels gar keine möglichkeit backspace zu benutzen. also genau dieses problem:
http://bugs.gentoo.org/2364
das lässt sich aber durch verwendung von "de-latin1" anstelle von "de-latin1-nodeadkeys" beheben und nicht wie angegeben durch veränderung der EXTENDED_KEYMAPS variablen.
es geht um die deutsche lokalisierung. die tutorials und anleitungen die man auf gentoo.org und diversen foren findet habe ich schon alle durch. ich habe auch schon sehr lange sehr viel rumexperimentiert es hat aber alles nicht funktioniert.
zum problem: in der konsole (nicht in kde!) kriege ich manchmal diesen nervigen fragezeichen-char wenn ich die backspace taste nutze. erzeugen kann ich das durch eingabe eines umlauts wie z.b. ö den ich dann mit backspace lösche. bestätige ich die eingabe taucht dieses fragezeichen auf. so kann ich z.b. auch den eingabe prompt löschen. ein weiteres backspace problem gibt es z.b. bei fdisk. dort kann ich die eingabe nicht löschen sondern er erzeugt mir entweder komische zeichen oder er löscht gar nicht.
ich habe es inzwischen aufgegeben aber vielleicht habe ich ja etwas ganz einfaches übersehen. hier mal relevante teile meiner config files. die auskommentierte dinge (und auch mehr) habe ich schon alle durchprobiert.
/etc/conf.d/consolefont
Code:
#CONSOLEFONT="default8x16"
CONSOLEFONT="lat9w-16"
#CONSOLEFONT="lat0-16"
#CONSOLETRANSLATION="8859-1_to_uni"
CONSOLETRANSLATION="8859-15_to_uni"/etc/rc.conf
Code:
UNICODE="yes"/etc/conf.d/keymaps
Code:
KEYMAP="de-latin1-nodeadkeys"
#KEYMAP="de-latin1"
#EXTENDED_KEYMAPS=""
EXTENDED_KEYMAPS="backspace keypad euro"
CONSOLEFONT="lat9w-16"
DUMPKEYS_CHARSET=""/etc/locale.gen
Code:
en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE@euro ISO-8859-15
de_DE.UTF-8 UTF-8diese Lokals wurden mit locale-gen generiert. (und beim emergen von glibc automatisch auch noch über 400 andere, weiß nicht ob das nötig ist/war)
/etc/env.d/02locale
Code:
#LANG="de_DE.UTF-8"
#GDM_LANG="de_DE.UTF-8"
#LC_COLLATE="C"
#LC_CTYPE="de_DE.UTF-8"nach diversen versuchen wurde immer env-update und source /etc/profile ausgeführt
eine lösung würde mich freuen auch wenn ich mich inzwischen schon fast daran gewöhnt habe.
Ergänzung ()
weiterhin habe ich auch im make menuconfig menu des kernels gar keine möglichkeit backspace zu benutzen. also genau dieses problem:
http://bugs.gentoo.org/2364
das lässt sich aber durch verwendung von "de-latin1" anstelle von "de-latin1-nodeadkeys" beheben und nicht wie angegeben durch veränderung der EXTENDED_KEYMAPS variablen.
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
gibt es denn hier keine gentoos außer Lt. Commander freak01 die das lokalisierung problem haben?
im übrigen bin ich vom prelinking durchaus positiv überrascht. wenn man kein hardened profil benutzt durchaus empfehlenswert und kinderleicht durchzuführen.
EDIT:
huch jetzt hab ich einen doppelpost gemacht. bin davon ausgegangen dass es nen ergänzung wird.
im übrigen bin ich vom prelinking durchaus positiv überrascht. wenn man kein hardened profil benutzt durchaus empfehlenswert und kinderleicht durchzuführen.
EDIT:
huch jetzt hab ich einen doppelpost gemacht. bin davon ausgegangen dass es nen ergänzung wird.
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
chinamaschiene schrieb:
Die Zeilen sind alle per "#" auskommentiert, dürften also nichts bewirken. Obs wirklich so ist kann man nur entscheiden, wenn man sich das Skript anschaut, was diese Datei auswertet. Jedenfalls müssen irgendwo im Boot- oder Loginprozess Variable wie LANG oder LC_CTYPE mit den gewünschten Werten initialisiert werden. Sonst funktioniert keine Lokalisierung. Am besten mal mit 'env' oder 'locale' nachschauen, ob die Variable gesetzt wurden.
Die Funktion von Sondertasten für Backspace u.ä. im Terminalfenster legt man mit stty fest, z.B. "stty erase ^H". Auch das sollte normalerweise in einem der Startskipte automatisch geschehen.
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
ja das auskommentieren war mal ein Test von mir für verschiedene werte. Aber:
Es funktioniert jetzt !!! wie schön :-). VIELEN DANK FÜR DEINE HILFE!
Es funktioniert jetzt !!! wie schön :-). VIELEN DANK FÜR DEINE HILFE!
Kommandofrosch
Lt. Junior Grade
- Registriert
- Okt. 2002
- Beiträge
- 484
Gentoo Hardened bei mir im Betrieb (/etc/make.conf):
Das ganze bezieht sich auf Hardened Features von Gentoo und den Gebrauch von SMP.
Man muss selber rausfinden, wie gut eine Multicore CPU skaliert.
Außerdem habe ich die Keywords auf meinem System auskommentiert um unstable zu sein.
Und wichtig ist es auf modular X zu migrieren(/etc/make.conf):
VIDEO_CARDS="nv welche_graka_drinne_ist"
INPUT_DEVICES="mouse keyboard und was_man noch_für_eingabegeräte hat"
Sonst baut man den ganzen Kram komplett, wofür braucht man die anderen 40 X-Treiber?
Bei ACCEPT_KEYWORDS="~ARCH" soll man das vollständige migrieren auf openrc und Baselayout 2 nicht vergessen.
--> etc-update && cd /etc/conf.d Hier passt man den rest an und führt zum Schluss dispatch-conf aus damit alles fehlerfrei übernommen wird.
Wichtig: Gentoo Hardened verwendet ein anderes Portage Profil.
Die Hardened Features machen bei anderen Profilen Probleme.
GCC, Binutils und Glibc sind speziell gepatched worden damit alles läuft.
Als CXX/CFLAGS solle man nur -fstack-protector und nicht -fstack-protector-all verwenden. Sonst versagt der Bau von Glibc.
Code:
linux@linux:/> cat /mnt/gentoo/etc/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-O2 -pipe -msse3 -fstack-protector"
CXXFLAGS="-O2 -pipe -msse3 -fstack-protector"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
USE="mmx sse sse2 mmap openmp hardened pic pie"
#
MAKEOPTS="-j4"
WANT_MP="true"
FEATURES="sandbox"
#
#ACCEPT_KEYWORDS="~amd64"Das ganze bezieht sich auf Hardened Features von Gentoo und den Gebrauch von SMP.
Man muss selber rausfinden, wie gut eine Multicore CPU skaliert.
Außerdem habe ich die Keywords auf meinem System auskommentiert um unstable zu sein.
Und wichtig ist es auf modular X zu migrieren(/etc/make.conf):
VIDEO_CARDS="nv welche_graka_drinne_ist"
INPUT_DEVICES="mouse keyboard und was_man noch_für_eingabegeräte hat"
Sonst baut man den ganzen Kram komplett, wofür braucht man die anderen 40 X-Treiber?
Bei ACCEPT_KEYWORDS="~ARCH" soll man das vollständige migrieren auf openrc und Baselayout 2 nicht vergessen.
--> etc-update && cd /etc/conf.d Hier passt man den rest an und führt zum Schluss dispatch-conf aus damit alles fehlerfrei übernommen wird.
Wichtig: Gentoo Hardened verwendet ein anderes Portage Profil.
Die Hardened Features machen bei anderen Profilen Probleme.
GCC, Binutils und Glibc sind speziell gepatched worden damit alles läuft.
Als CXX/CFLAGS solle man nur -fstack-protector und nicht -fstack-protector-all verwenden. Sonst versagt der Bau von Glibc.
Zuletzt bearbeitet:
- Registriert
- März 2002
- Beiträge
- 3.311
kleine Ergänzung:
wenn man die neuste Hardened-Toolchain verwendet mit gcc-4.x, ist es nicht nötig, extra
-fstack-protector -fstack-protector-all -D_FORTIFY_SOURCE=2
in den CFLAGS und CXXFLAGS anzugeben, weiters sind die -Wl,-z,relro und -Wl,-z,now flags unter LDFLAGS auch schon fest in den Specs angegeben
[man kann die hardened Flags auch im normalen Profil freischalten, dies sollten allerdings nur erfahrene Benutzer tun und wegen der zusätzlichen USE-flags im normalen Desktop-Profil ist es auch aus Sicherheitsgründen eher weniger sinnvoll - aber mir reicht es ^^ ]
wenn man die neuste Hardened-Toolchain verwendet mit gcc-4.x, ist es nicht nötig, extra
-fstack-protector -fstack-protector-all -D_FORTIFY_SOURCE=2
in den CFLAGS und CXXFLAGS anzugeben, weiters sind die -Wl,-z,relro und -Wl,-z,now flags unter LDFLAGS auch schon fest in den Specs angegeben
[man kann die hardened Flags auch im normalen Profil freischalten, dies sollten allerdings nur erfahrene Benutzer tun und wegen der zusätzlichen USE-flags im normalen Desktop-Profil ist es auch aus Sicherheitsgründen eher weniger sinnvoll - aber mir reicht es ^^ ]
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
Ist es normal das ich beim compilen nur 40-60% cpu-auslastung maximal habe. das system ist ein dual core und ich habe -j3 gesetzt. muss man da noch irgendwas ändern? top, kde und mpstat sagen alle ungefähr gleiche werte. mir wäre nen 100% auslastung lieber. oder throttelt der cpu weil der ultra heiß ist? wie kann ich das prüfen?
OT:
OT:
kein kde mehr? ;-)
- Registriert
- März 2002
- Beiträge
- 3.311
*) entweder -j3 auf -j5 raufsetzen
oder
*) echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features
als root, damit wird das buggy fair scheduling vom cpu-scheduler CFS abgeschaltet und dem Verhalten von BFS angenähert
alternativ:
*) den Kernel mit BFS patchen und diesen testen (falls du experimentierfreudig bist)
zum throttling:
cat /proc/acpi/processor/CPU0/throttling
und
cat /proc/acpi/processor/CPU1/throttling
alles was NICHT T0: 100%
markiert ist (durch *), ist gethrottelt
Temperaturen kannst du per "sensors" abrufen (vorher:
ausführen)
damit die CPU schneller hochtaktet:
den ondemand governor verwenden:
http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling
OT:
ja, kde4 ist mir einfach (noch) zu lahm mit (fglrx und) compositing, weiters funktioniert das "negative" plugin nicht mit fglrx (?!)
oder
*) echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features
als root, damit wird das buggy fair scheduling vom cpu-scheduler CFS abgeschaltet und dem Verhalten von BFS angenähert
alternativ:
*) den Kernel mit BFS patchen und diesen testen (falls du experimentierfreudig bist)
zum throttling:
cat /proc/acpi/processor/CPU0/throttling
und
cat /proc/acpi/processor/CPU1/throttling
alles was NICHT T0: 100%
markiert ist (durch *), ist gethrottelt
Temperaturen kannst du per "sensors" abrufen (vorher:
Code:
emerge lm_sensors && sensors-detect && /etc/init.d/lm_sensors start && rc-update add lm_sensors defaultdamit die CPU schneller hochtaktet:
den ondemand governor verwenden:
http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling
OT:
ja, kde4 ist mir einfach (noch) zu lahm mit (fglrx und) compositing, weiters funktioniert das "negative" plugin nicht mit fglrx (?!)
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
vielen dank für deine exzellente antwort :-)
"echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features"
dieses scheint es bei meinen aktuellen 2.6.30 gentoo-sources zumindest nicht zu geben. auch ein find /proc/ -iname '*sched*' bzw. find /sys/ -iname '*sched*' brachte mir keine solche einstellung. das mit dem BFS werde ich demnächst ausprobieren. hoffe nur dass nicht das gleiche passiert wie mit meinem test vom btrfs. aber wer nicht wagt...
zum throttling:
cat /proc/acpi/processor/CPU0/throttling
cat /proc/acpi/processor/CPU1/throttling
merkwürdigerweise heißen die bei mir CPU1 und CPU2 (sehr unlinuxartig). aber egal.
noch merkwürdiger ist das ich "<not supported>" für beide kerne (Conroe Core2Duo E6600)
erhalte.
den ondemand governer habe ich bereits aktiviert.
temperaturen habew ich schon ausgelesen ich weiß nur nicht ob ich den werten glauben darf. selbst das BIOS sagt im idle 50-55 grad. glaub ich nicht ist alles richtig montiert. ausserdem ist es mir auch nicht so wichtig ob und wie lange der prozessor das aushält wenn es doch stimmt.
EDIT
ach und zum xfce: sieht das den vergleichbar gut wie kde mit compositing desktpeffekten aus? gibt es da irgendwo aktuelle screenshots oder videos? ich möchte schon das der desktop gut aussieht. da finde ich gnome schon viel zu hässlich. sieht aus wie von 1996.
"echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features"
dieses scheint es bei meinen aktuellen 2.6.30 gentoo-sources zumindest nicht zu geben. auch ein find /proc/ -iname '*sched*' bzw. find /sys/ -iname '*sched*' brachte mir keine solche einstellung. das mit dem BFS werde ich demnächst ausprobieren. hoffe nur dass nicht das gleiche passiert wie mit meinem test vom btrfs. aber wer nicht wagt...
zum throttling:
cat /proc/acpi/processor/CPU0/throttling
cat /proc/acpi/processor/CPU1/throttling
merkwürdigerweise heißen die bei mir CPU1 und CPU2 (sehr unlinuxartig). aber egal.
noch merkwürdiger ist das ich "<not supported>" für beide kerne (Conroe Core2Duo E6600)
erhalte.
den ondemand governer habe ich bereits aktiviert.
temperaturen habew ich schon ausgelesen ich weiß nur nicht ob ich den werten glauben darf. selbst das BIOS sagt im idle 50-55 grad. glaub ich nicht ist alles richtig montiert. ausserdem ist es mir auch nicht so wichtig ob und wie lange der prozessor das aushält wenn es doch stimmt.
EDIT
ach und zum xfce: sieht das den vergleichbar gut wie kde mit compositing desktpeffekten aus? gibt es da irgendwo aktuelle screenshots oder videos? ich möchte schon das der desktop gut aussieht. da finde ich gnome schon viel zu hässlich. sieht aus wie von 1996.
Zuletzt bearbeitet:
E
enteon
Gast
chinamaschiene schrieb:
http://upload.wikimedia.org/wikipedia/commons/7/71/Xfce-4.4.png
finde ich schon sehr gnome-hässl...äh..artig.
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
Was compilierst du denn? Wenn "make" die einzelnen Schritte nicht parallelisieren kann, z.B. weil die einzelnen Schritte jeweils aufs Ergebnis des Schritts davor angewiesen sind, nützt dir ein "-j sonstwieviel" gar nichts. Also am besten erstmal einen Blick aufs Makefile werfen ...chinamaschiene schrieb:
Zuletzt bearbeitet:
chinamaschiene
Lt. Commander
- Registriert
- Mai 2008
- Beiträge
- 1.257
das xfce bild habe ich auch gesehen. (einzigstes) immerhin hat es transparenz effekte ansonsten. stimme ich dir voll zu. sehr "gnomig".
zum compilieren: da dies ja ein gentoo thread ist nutze ich ja gentoo das heißt ich kompiliere bei nen neuinstallation mindestens 300-400 pakete. alleine das monatliche kde update geht schon an die 100. da kann ich bei bestem willen nicht sagen was in den makefiles drinsteht ;-)
ach ja:
als gentoo tip wurde ja schon das automatische erzeugen von binary packages gesagt. entweder mit -b option bei emerge oder fest in der make.conf. nun würde ich gerne ältere binaries löschen. gibt es dafür sowas wie nen praktisches shell skript (mit find und sed/grep oder auch awk) oder muss ich da mit selber mühe geben und ein aufwändiges (schlechtes?) skript selber erstellen. schön wäre es wenn es die notwendigen pakete inklusive dependencies aus z.b. emerge -ep world ausliest (oder /var/db/portage?) und dann in /usr/portage/packages alle älteren pakete löscht.
vielleicht hat ja jemand schon sowas oder kann sowas leicht machen und postet es hier. das würde vielen gentoos
helfen...
zum compilieren: da dies ja ein gentoo thread ist nutze ich ja gentoo das heißt ich kompiliere bei nen neuinstallation mindestens 300-400 pakete. alleine das monatliche kde update geht schon an die 100. da kann ich bei bestem willen nicht sagen was in den makefiles drinsteht ;-)
ach ja:
als gentoo tip wurde ja schon das automatische erzeugen von binary packages gesagt. entweder mit -b option bei emerge oder fest in der make.conf. nun würde ich gerne ältere binaries löschen. gibt es dafür sowas wie nen praktisches shell skript (mit find und sed/grep oder auch awk) oder muss ich da mit selber mühe geben und ein aufwändiges (schlechtes?) skript selber erstellen. schön wäre es wenn es die notwendigen pakete inklusive dependencies aus z.b. emerge -ep world ausliest (oder /var/db/portage?) und dann in /usr/portage/packages alle älteren pakete löscht.
vielleicht hat ja jemand schon sowas oder kann sowas leicht machen und postet es hier. das würde vielen gentoos
helfen...
Zuletzt bearbeitet:
Revontulet
Ensign
- Registriert
- Apr. 2004
- Beiträge
- 233
Ich glaube, du solltest dir mal eclean angucken
