Kernel Konfiguration -> minimal, lohnt es sich?
Kernel Konfiguration -> minimal, lohnt es sich?
Mich würde mal interessieren wie eure Kernelkonfiguration aussieht.
Mal angenommen man installiert sich per apt-get die sources und ruft die Kernelkonfiguration auf. Standardmäßig ist da ja sehr viel unnützes dabei (fürs eigene System), ich denke mal um ein möglichst breites Spektrum an Hardware zu unterstützen.
Betrachtet man nun ausschließlich das eigene System, lässt sich ja sehr viel abschalten bzw deaktivieren.
Wenn man wirklich alles deaktiviert, was das eigene System nicht braucht, hat man dadurch Vorteile? Spürt man diese Vorteile (Performance) gegenüber einem Kernel mit Standardkonfig?
Verwendet ihr so ziemlich die Standardkonfig oder wie ichs angesprochen habe nur das nötigste fürs eigene System?
mfg opoderoso
Mal angenommen man installiert sich per apt-get die sources und ruft die Kernelkonfiguration auf. Standardmäßig ist da ja sehr viel unnützes dabei (fürs eigene System), ich denke mal um ein möglichst breites Spektrum an Hardware zu unterstützen.
Betrachtet man nun ausschließlich das eigene System, lässt sich ja sehr viel abschalten bzw deaktivieren.
Wenn man wirklich alles deaktiviert, was das eigene System nicht braucht, hat man dadurch Vorteile? Spürt man diese Vorteile (Performance) gegenüber einem Kernel mit Standardkonfig?
Verwendet ihr so ziemlich die Standardkonfig oder wie ichs angesprochen habe nur das nötigste fürs eigene System?
mfg opoderoso
Meine .config habe ich ganz von vorne begonnen und nur das ausgewählt, was ich tatsächlich brauche. Dauert natürlich, bis alles 100%ig passt.
Von der Performance her spüre ich nichts. Würde mich auch wundern, weil udev nur die nötigen Module lädt.
Von der Performance her spüre ich nichts. Würde mich auch wundern, weil udev nur die nötigen Module lädt.
Gruß, Marcus
„Well done! We did it!“
Debian testing
kernel 2.6.18.3
IBM R50e UR0S5GE
„Well done! We did it!“
Debian testing
kernel 2.6.18.3
IBM R50e UR0S5GE
Habe auch alles rausgeschmissen. Das .deb ist 1,2MB groß. Das Booten geht vielleicht 5s schneller. Insgesamt lohnt sich der Zeitaufwand ja nicht wirklich. Ist aber ne ganz nette Sache nur das an Bord zu haben was man braucht. Sicherheitsmäßig schadet es sicher-lich nicht, wenn man was rausnimmt...
Gruß, Carl
Gruß, Carl
Ich baue meine Kernel auch nur mit dem was ich an Hardware besitze. Der Nachteil ist, wenn ein Kumpel kommt mit einer SD Card oder egal was, die ich nicht selber habe geht das Kernel bauen wieder los.
Debian Testing | 2.6.22.9 | KDE 3.5.7| Asus P5B Deluxe| Core² Quad E6600@3500MHz| 2x1024 GSKILL PC6400 2GBHZ| Gainwarde 6600 GT | 200GB Samsung SATA| 500GB Samsung SATA | wakü| Laing |Mips Freezer Set| LianLi PC-70
Dafür hat man dann noch den Debian-Kernel.Harald.O hat geschrieben:Ich baue meine Kernel auch nur mit dem was ich an Hardware besitze. Der Nachteil ist, wenn ein Kumpel kommt mit einer SD Card oder egal was, die ich nicht selber habe geht das Kernel bauen wieder los.
Gruß, Marcus
„Well done! We did it!“
Debian testing
kernel 2.6.18.3
IBM R50e UR0S5GE
„Well done! We did it!“
Debian testing
kernel 2.6.18.3
IBM R50e UR0S5GE
@H4kk3r
Genau so ist es
Man spart sich ein haufen Arbeit, wenn man den von Debian nimmt.
Genau so ist es
Man spart sich ein haufen Arbeit, wenn man den von Debian nimmt.
Debian Testing | 2.6.22.9 | KDE 3.5.7| Asus P5B Deluxe| Core² Quad E6600@3500MHz| 2x1024 GSKILL PC6400 2GBHZ| Gainwarde 6600 GT | 200GB Samsung SATA| 500GB Samsung SATA | wakü| Laing |Mips Freezer Set| LianLi PC-70
...
um nochmals auf den ausgangspunkt zurückzukommen:
meinem ersten kernel (den ich auch benutzen konnte, haha ) hab ich noch eine ramdisk an die hand gegeben. dann hab ich angefangen (eben nach der minimalistischen devise alles schön kompakt zu halten) nicht nur auf die ramdisk zu verzichten und das zeug fest mit rein zu nehmen, sondern auch gleich in der config alle module außen vor zu lassen, bei denen ich der meinung war, dass ich sie eh nie brauchen würde. aber natürlich braucht man irgendwann ein bestimmtes modul (und sei es auch nur, dass man ein bestimmtes modul aus reiner dummheit nicht kompiliert hat) und dann muss man nochmal einen bauen... (naja, natürlich kann man die alte config benutzen und ergänzen - aber trotzdem)
alles in allem nehm ich mittlerweile sehr vieles als modul mit, wenn ich denke, das könnte ich doch vielleicht mal brauchen einen geschwindigkeitsunterschied hab ich auch nicht feststellen können (aber das wurde ja schon gesagt... ^)
meinem ersten kernel (den ich auch benutzen konnte, haha ) hab ich noch eine ramdisk an die hand gegeben. dann hab ich angefangen (eben nach der minimalistischen devise alles schön kompakt zu halten) nicht nur auf die ramdisk zu verzichten und das zeug fest mit rein zu nehmen, sondern auch gleich in der config alle module außen vor zu lassen, bei denen ich der meinung war, dass ich sie eh nie brauchen würde. aber natürlich braucht man irgendwann ein bestimmtes modul (und sei es auch nur, dass man ein bestimmtes modul aus reiner dummheit nicht kompiliert hat) und dann muss man nochmal einen bauen... (naja, natürlich kann man die alte config benutzen und ergänzen - aber trotzdem)
alles in allem nehm ich mittlerweile sehr vieles als modul mit, wenn ich denke, das könnte ich doch vielleicht mal brauchen einen geschwindigkeitsunterschied hab ich auch nicht feststellen können (aber das wurde ja schon gesagt... ^)
danke erstmal für die vielen Antworten.
Nun würde mich noch ein interessieren.
Was haltet ihr von den optionen
> PREEMPT_VOLUNTARY - Voluntary Kernel Preemption (Desktop)
> PREEMPT - Preemptible Kernel (Low-Latency Desktop)
gegenüber der Standardoption
> PREEMPT_NONE - No Forced Preemption (Server)
?
Nun würde mich noch ein interessieren.
Was haltet ihr von den optionen
> PREEMPT_VOLUNTARY - Voluntary Kernel Preemption (Desktop)
> PREEMPT - Preemptible Kernel (Low-Latency Desktop)
gegenüber der Standardoption
> PREEMPT_NONE - No Forced Preemption (Server)
?
ich hab mir vorhin mal einen gemacht mit PREEMPT - Preemptible Kernel (Low-Latency Desktop) auf Basis von 2.6.17.7 von kernel.org.
Am Systemstart hat sich nichts getan, aber die Aufrufzeiten von versch. Programmen kommen mir irgendwie ein wenig flotter vor.
kA ob das nur Einbildung ist oder ob es wirklich etwas schneller geht.
Probleme hatte ich bisher noch keine.
Am Systemstart hat sich nichts getan, aber die Aufrufzeiten von versch. Programmen kommen mir irgendwie ein wenig flotter vor.
kA ob das nur Einbildung ist oder ob es wirklich etwas schneller geht.
Probleme hatte ich bisher noch keine.
Ich mach auch gern meine eigenen, schon weil ich von der initrd nicht viel halte - ist zwar in gewissen faellen sehr nuetzlich, aber den Fall hatte ich (eigentlich) noch nie.
Nicht alles drin zu lassen hat schon mal einen Vorteil: man spart sich wohl (geschaetzt) bis zu 70% der compile-dauer.
Nachteil: man braucht als erfahrenerer schon >15 Minuten um sich durchs Menu zu wuehlen.
Workaround: man nimmt immer wieder die gleiche .config, bzw. bindet die mit nach /proc/config.gz ein, und unziped/cat'd die bei der neuen Kernelversion nach /usr/linux/src .
Performancegewinn gibts eigentlich kaum, vielleicht beim boot ( hab gerade mal 2-3 Module, kqemu (qemu) und ein rt2500 (sourceforge) und lirc.
Wenn man mal neue software installiert, reicht eigentlich meis (!) ein "make menuconfig;make modules_install" - dabei wird nur das eine Modul compiliert, und eben die abhaengigkeiten die es mit sich bringt; was wiederum doch einen Kernel-neubau notwendig macht.
Auf jeden fall denke ich man bekommt den Einblicke die man sonst nicht hat.
Trotzdem habe ich mich dazu durchgerungen das lediglich noch auf dem Desktop zu machen - ist gut, gerade wenn ich neue Hardware installiere. Ich tu mir schwer das mit dem Kernel-Headers-Package zu verstehen - klappt bei mir eher selten damit. Ich hab schon lieber die sourcen da, damit gehts immer.
Nicht alles drin zu lassen hat schon mal einen Vorteil: man spart sich wohl (geschaetzt) bis zu 70% der compile-dauer.
Nachteil: man braucht als erfahrenerer schon >15 Minuten um sich durchs Menu zu wuehlen.
Workaround: man nimmt immer wieder die gleiche .config, bzw. bindet die mit nach /proc/config.gz ein, und unziped/cat'd die bei der neuen Kernelversion nach /usr/linux/src .
Performancegewinn gibts eigentlich kaum, vielleicht beim boot ( hab gerade mal 2-3 Module, kqemu (qemu) und ein rt2500 (sourceforge) und lirc.
Wenn man mal neue software installiert, reicht eigentlich meis (!) ein "make menuconfig;make modules_install" - dabei wird nur das eine Modul compiliert, und eben die abhaengigkeiten die es mit sich bringt; was wiederum doch einen Kernel-neubau notwendig macht.
Auf jeden fall denke ich man bekommt den Einblicke die man sonst nicht hat.
Trotzdem habe ich mich dazu durchgerungen das lediglich noch auf dem Desktop zu machen - ist gut, gerade wenn ich neue Hardware installiere. Ich tu mir schwer das mit dem Kernel-Headers-Package zu verstehen - klappt bei mir eher selten damit. Ich hab schon lieber die sourcen da, damit gehts immer.
Watt about the non-digital!?