[Eisfair] kthreadd invoked oom-killer

[Thomas Bork]

Am 02.06.2017 um 22:11 schrieb Uwe Kunze:

> Außerdem fehlen mir die Quellen für die closed-Source-Treiber (AVM, 
> dahdi), so dass ich keinen wirklich brauchbar produktiven Kernel 
> erzeugen könnte.

Die kommen nicht von mir, sondern von Holger. Möglicherweise laufen die 
alten Module nach der Änderung, möglicherweise auch nicht. Wenn sie 
nicht laufen, müsstest Du also auch noch Holger bitten, neue Module zur 
Verfügung zu stellen.

> Aber mal davon abgesehen ... es MUSS doch einen plausiblem Grund für 
> diesen Mist mit dem angeblichen Speichermangel geben.

Den wird es sicherlich geben. Nur ist im Moment wieder ziemlich unklar wo.

> Warum sollen Programme (ob als eisfair-Paket oder aus anderen Sourcen 
> kompiliert), die unter einem Kernel problemlos funktionieren, auf einmal 
> unter einem anderen Kernel fehlerhaft sein ?

Siehe als Beispiel (und _nur_ als Beispiel, denn THP haben wir m.E. 
bereits ausgeschlossen) jemalloc und Kernel-Versionen mit oder ohne THP. 
Das, was vorher problemlos funktioniert hat, muss es hinterher _unter 
anderen Gegebenheiten_ nicht mehr zwangsläufig tun. Also stellt man 
entweder die alten Gegebenheiten wieder her (THP abschalten) oder passt 
die Software (jemalloc) an die neuen Gegebenheiten (THP) an. Das ist 
doch Tagesgeschäft in der Softwarebranche.

> Es kann m.E. nach nicht richtig sein, die "Schuld" einzig auf die 
> Anwendersoftware zu schieben. Was sollte man Deiner Meinung nach noch 
> tun, außer das, was wir bereits gemacht haben ?

Schuldzuweisungen sind mir Wurst. Im Moment habe ich keine weitere Idee 
mehr, wo es hängt.

> https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/ 

Was da besprochen wurde, ist mit 3.16.x nicht vergleichbar, da die 
Probleme verursachenden Patches erst in 4.7 eingebaut wurden. Siehe

Siehe

https://lwn.net/Articles/668126/
http://lkml.iu.edu/hypermail/linux/kernel/1608.2/04321.html

-- 
der tom
[eisfair-team]