[Eisfair] [E1] zu hohe CPU-Auslastung nach einigen Tagen bei aktivem Apache2 und owncloud Nutzung, speziell Kalender / eisgraph-Installation

[Thomas Bork]

Am 26.09.2015 um 10:13 schrieb Marcus Roeckrath:

>> eisgcc # ls -la /boot/kernel*
>> -rw-r--r-- 1 root root 2777792 Sep 25 17:26 /boot/kernel
>> -rw-r--r-- 1 root root 2281648 Sep 22 19:18 /boot/kernel.old
>> wobei diese größere Differenz meines Erachtens nicht
>> ausschließlich aus dem Setzen der Optionen
> Vielleicht sieht Toms Buildprozess ein wenig anders aus.

Das halte ich für unwahrscheinlich, wenn Ansgar nicht sehr exotisch 
vorgegangen ist.

>> CONFIG_TASKSTATS=y
>> CONFIG_TASK_DELAY_ACCT=y
>> CONFIG_TASK_XACCT=y
>> CONFIG_TASK_IO_ACCOUNTING=y
>> kommen kann.

Ansgar hat sehr wahrscheinlich einfach kernel-dev installiert, per 'make 
menuconfig' die obigen Optionen gesetzt, den Kernel gebaut und installiert.

Meine Vorgehensweise ist da auch nicht anders. Ich achte penibel darauf, 
dass alle vom eisfair-Kernel verwendeten Patches in kernel-dev enthalten 
sind, damit man aus den Quellen nachvollziehbar den offiziellen 
eiskernel bauen kann (es hat mich immer geärgert, dass das bei eisfair-2 
so nicht war).

Wenn man also kernel-dev installiert und die Konfiguration *nicht* 
verändert, unterscheidet sich ein vom Anwender gebauter Kernel maximal 
an 2 Punkten vom offiziellen eiskernel:

1.
Der vom Anwender gebaute Kernel ist maximal ein paar Byte grösser oder 
kleiner, als der im Kernel-Paket ausgelieferte. Dieser 
Grössen-Unterschied liegt am Pack-Verfahren des Kernels. Er tritt auch 
bei 2 aufeinander folgenden 'make install'-Läufen auf einem 
unveränderten System auf.

2.
Die vom Anwender gebauten Module sind geringfügig grösser, als die im 
Kernel-Paket ausgelieferten, da ich (um die Download-Grösse gering zu 
halten) die Debug-Informationen mittels 'strip -g' aus den Modulen strippe.

Alle anderen Grössen-Unterschiede sind daher Ergebnis einer veränderten 
Konfiguration.

> Wenn wir da auf eisfair auf breiter Linie dazu auffordern,

Ich fordere nicht in breiter Linie dazu auf, angepasste eiskernel zu 
erstellen. Aber ich wäge durchaus ab, ob ein *vereinzelter* Wunsch nach 
speziellen Features es rechtfertigt, den offiziellen eiskernel für 
*alle* aufzublähen.

Mit der selben Begründung könnte man nämlich auch x Treiber fest (und 
nicht als Modul) in den Kernel integrieren, die aber 90% aller Anwender 
gar nicht benötigen, weil sie die entsprechende Hardware nicht besitzen...

-- 
der tom
[eisfair-team]