Nvidia’s kernel module nvidia_uvm kills normal operation of the lsns command

Whilst preparing a second blog post about network namespaces I stumbled across a really strange bug:

Whenever one starts LibreOffice (with the OpenCL-options activated) the command “lsns” stops producing output. Not funny, as one may consider namespaces and operations investigating the namespace settings for Linux processes security relevant. So, I looked a bit into it …

“strace” led me to processes which were Nvidia related. Actually, on my Linux PC, I use the proprietary Nvidia driver 384.98 for my graphics card. The cause behind the trouble with LibreOffice is that the OpenCL-options of LO trigger loading the kernel module “nvidia_uvm”. This module supports CUDA operations – which seem to be used by some recent versions Linux programs as LO and also GIMP.

However, as soon as “nvidia_uvm” is loaded the command “lsns” stops producing output. This should not happen as “lsns” uses standard kernel interfaces for investigating process properties …???…

I have no remedy for this – and am waiting for an answer from the Nvidia developer forum. But at least in case of LibreOffice you can avoid this irritating bug by unsetting the OpenCL options ….

Opensuse Leap 42.2, Android, KDE, Dolphin – Dateitransfer mit MTP – Probleme und mögliche Ursachen

Vor einiger Zeit habe ich auf einigen Geräten ein Upgrade auf Leap 42.2 vorgenommen. Das lief alles ganz OK. Nun wollte ich von einem der betroffenen Laptops Dateien auf ein Smartphone übertragen. Dabei stolperte ich bei Einsatz von “MTP” und dem zugehörigen kio-Slave “kio_mtp” unter KDE in ähnliche Probleme, wie sie unter den folgenden Links beschrieben sind:

http://linux-club.de/forum/viewtopic.php?t=121313
https://forums.opensuse.org/showthread.php/526021-Erneute-Probleme-beim-Zugriff-auf-Android-Smartphone-via-MTP
https://forums.oneplus.net/threads/zugriff-auf-daten-ueber-computer.598702/

Ich weiß nicht, ob meine Problem die gleichen Ursachen hatten, wie bei meinen Leidensgenossen – aber die nachfolgenden Punkte sind jedenfalls der Beachtung wert.

Typischer fehlerhafter Verlauf beim Einsatz von “mtp” unter KDE

Fehler 1: Zugriff auf das erkannte Smartphone führt zu keiner Verzeichnisanzeige unter Dolphin

Man schließt das Smartphone an; es kommt zuerst eine Freigabeaufforderung auf dem Smartphone. Danach öffnet man Dolphin – und dann kommt da erneut eine Warnhinweis, dass man das Smartphone freigeben/entsperren müsse; tatsächlich erscheint am Phone eine neue Aufforderung. Die bestätigt man und schließt danach das Popup in Dolphin. Anschließend lädt und lädt Dolphin den Ordnerinhalt angeblich – es passiert aber weiter nichts und zur Anzeige der Speichermedien des Smartphones und deren Inhalte kommt es nie.

Fehler 2: Dolphin kann aus dem Gerätemanager heraus nicht gestartet werden

Ein weiterer ärgerlicher Punkt war in meinem Fall der, dass unter der Geräteüberwachung zwar Dolphin-Icons als Optionen für “Aktionen” angezeigt wurden; ein Klick darauf führte aber jedesmal zu einer Fehlermeldung, die man wegklicken muss. Dolphin öffnet sich dann aber nicht.

Ein solches Verhalten macht einen wahnsinnig; im besonderen, wenn man unter Zeitdruck steht und man weiß, dass früher alles schon mal funktioniert hat. In meinem Fall halfen mir “kde-connect” und die zugehörige App auf dem Smartphone aus der unmittelbaren Patsche heraus, weil beide Geräte (Laptop, Smartphone) sich zufällig im selben WLAN befanden. In unserer Firma gibt es aber Geräte, die aus Sicherheitsgründen in anderen WLAN-Netzen als die Smartphones hängen. Da hilft KDE-Connect nichts. Nun kann man auf SSH-/FTPS-Verbindungen ausweichen. MTP wäre aber doch so einfach … warum sollte das unter Leap nicht gehen?

Ein paar Experimente

Ich habe dann in meinem Ärger ein wenig rumexperimentiert. Als erster Schritt zur Analyse hilft in einem solchen Fall oft, das Ganze mal mit einem frisch angelegten User oder als User “root” auszuprobieren; Letzteres, um evtl. Rechteprobleme festzustellen.

In meinem Fall reichte schon der erste Schritt: Mit frisch angelegten UserIDs gab es kein größeres Problem mit MTP und einer USB-Kabelverbindung zu unseren verschiedenen Smartphones (LG 2, Samsung Note, Samsung 6). Da lief alles wie erwartet: Anschließen des USB-Kabels an die Linux Workstation, Dolphin öffnen, Android Phone wählen, auf dem Phone die angeforderte MTP-Verbindung freigeben, kurz warten, in Dolphin mit F5 die Ansicht aktualisieren und schließlich durch die Datenträger des Smartphones browsen und Dateien zwischen den Geräten hin und her kopieren.

Workaround

Das brachte mich zu einem ersten Workaround, den ich hier aufliste, weil er vielleicht beim einen oder anderen auch helfen mag. Auf die tatsächlichen
Ursachen der Fehler in meiner Konfiguration gehe ich weiter unten ein.

Man lösche – soweit vorhanden – die Dateien “~/.config/dolphinrc”, “~/.kde4/share/config/dolphinrc” und das Verzeichnis “~/.local/share/dolphin”. Danach funktionierte folgender Workaround relativ zuverlässig:

  • Schritt 1: Anschluss des Smartphone per USB-Kabel an das OS Leap 42.2-Gerät.
  • Schritt 2: I.d.R. kommt keine Freigabeaufforderung auf dem Handy – falls doch: bestätigen.
  • Schritt 3: Geräteüberwachung im Systemtray (Systembereich der Kontrollleiste) öffnen.
  • Schritt 4: Optionen für Android-Gerät anzeigen lassen und auf erstes Dolphin-Symbol klicken.
  • Schritt 5: Fehlermeldung wegklicken und ggf. auftauchende Freigabeaufforderung auf dem Handy positiv beantworten.
  • Schritt 6: Erneut Geräteüberwachung öffnen.
  • Schritt 7: Diesmal auf das 2-te Dolphin-Symbol klicken.
  • Schritt 8: Erneut Fehlermeldung wegdrücken und ggf. Freigabeaufforderung auf dem Handy bestätigen.
  • Schritt 9: Dolphin unabhängig auf dem Desktop öffnen => dort das unter “Geräte” angezeigte > Android-Phone anklicken.
  • Schritt 10: Es werden die auf dem Smartphone verfügbaren Speicherbereiche (Standard “Phone” und (SD-) “Card” angezeigt.

Bei mir tauchte entweder bei Schritt 5 oder bei Schritt 6 eine Freigabeaufforderung auf. Nicht aber zweimal. Die oben beschriebene Schrittfolge ist die einzige, die bei mir zuverlässige Ergebnisse vor den weiter unten geschilderten Maßnahmen produzierte. Der Workaround beseitigte jedoch nicht das Problem des Fehlers beim Klick auf die Dolphin-Symbole in der Geräteüberwachung.

Dieser Zustand ist aus meiner Sicht absurd. Offenbar funktioniert die MTP-Verbindung im Prinzip – aber irgendetwas in der initialen Dialogführung zwischen kio_mtp, Dolphin und dem Android-Phone stimmte einfach nicht.

Lösung 1: Amarok’s MTP-Modul muss abgeschaltet werden!

Ich stelle auf einigen meienr Geräten entweder Amarok und Clementine beim KDE-Start zur Verfügung. Sowohl auf dem Laptop als auch auf der Workstation waren nach dem Start von KDE Amarok aktiv. (Auf er Arbeitstation übrigens, weil ich mich gerade mal wieder mit Pulseaudiio herunmschlage. Dazu mehr in einem kommenden Beitrag.)

Es hat mich eine Weile gekostet herauszufinden, dass Amarok standardmäßig das Modul “MTP-Sammlung” aktiviert. Nun stammt Amarok aus KDE4-Zeiten. Das Modul ist offenbar nicht mehr mit der aktuellen KDE5-Umgebung kompatibel oder interferiert in unzulässigerweise mit über “udev” festgelegten Reaktionen auf MTP-Ereignisse.

Also unbedingt im Dialog “Amarok >> Einstellungen >> Amarok Einrichten >> Module” das Modul “MTP-Sammlung” deaktivieren !

Dass dieses Modul wirklich Ungutes tut, kann man dadurch ausprobieren, dass man bei aktiver MTP-Verbindung das Modul mal wieder aktiviert! Viel Glück …

Lösung 2: KDE-Einstellung unter Standardanwendungen überprüfen

Mein zweiter Fehler hatte damit zu tun, dass ich irgendwann mal “PCManFM” als Dateimanager installiert hatte. Der hatte sich dann selbst in den KDE-Einstellungen als primärer Manager für die Dateiverwaltung hinterlegt. Das funktioniert aber nicht mit der KDE-Geräteüberwachung. Also unter
“systemsettings5 >> Anwendungen >> Standardanwendungen >> Dateiverwaltung” Dolphin als Standard-Dateimanager festlegen.

Schließe ich nun eines unseres Android Smartphones an die Linux-Geräte an, auf denen das erlaubt ist, so funktioniert MTP wieder schnell und flüssig – egal ob an einem USB2.0 oder 3.0-
Anschluss.

Fazit

Plugins oder Module von Applikationen, die MTP-Ereignisse erkennen und auf die dahinter liegenden Geräte zugreifen wollen, kommen als potentielle Ursachen von Problemen mit MTP-Verbindungen unter KDE und Dolphin in Frage. Unter Opensuse Leap 42.2 gilt das auf jeden Fall für das MTP-Modul von Amarok. Es ist aber gut vorstellbar, dass auch andere Anwendungen ähnliche Probleme, wie oben diskutiert, zeitigen können. In Frage kommen vor allem Multimedia-Anwendungen. Der KDE-User sollte hierauf eine Auge haben und nach der Installation solcher Anwendungen Tests zu MTP-Verbindungen durchführen.

Viel Spaß weiterhin mit Dateitransfers zu Smartphones – macht das aber bitte nur auf Geräten, auf denen die impliziten Sicherheitsrisiken einer Smartphone-Anbindung kontrollierbar sind, und nur für User mit minimalen Rechten …

Performance of Linux md raid-10 arrays – negative impact of the intel_pstate CPU governor for HWP?

Last November I performed some tests with “fio” on Raid arrays with SSDs (4 Samsung EVO 850). The test system ran on Opensuse Leap 42.1 with a Linux kernel of version 4.1. It had an onboard Intel Sunrise Point controller and an i7 6700k CPU.

For md-raid arrays of type Raid10, i.e. for Linux SW Raid10 arrays created via the mdadm command, I was quite pleased with the results. Both for N2 and F2 layouts and especially for situations where the Read/Write load was created by several jobs running in parallel. Depending on the size of the data packets you may, e.g., well reach a Random Read [RR] performance between 1.0 Gbyte/sec and 1.5 GByte/sec for packet sizes ≥ 512 KB and %gt; 1024k, respectively. Even for one job only the RR-performance for such packet sizes lay between 790 MByte/sec and 950 Mbyte/sec – i.e. well beyond the performance of a single SSD.

Significant drop in md-raid performance on Opensuse Leap 42.2 with kernel 4.4

Then I upgraded to Opensuse Leap 42.2 with kernel 4.4. Same system, same HW, same controller, same CPU, same SSDs and raid-10 setup.
I repeated some of my raid-array tests. Unfortunately, I then experienced a significant drop in performance – up to 25% depending on the packet size. With absolute differences in the range of 60 MByte/sec to over 200 Mbyte/sec, again depending on the chosen data packet sizes.

In addition I saw irregular ups and downs in the performance (large spread) for repeated tests with the same fio parameters. Up to some days ago I never found a convincing reason for this strange performance variation behavior of the md-Raid arrays for different kernels and OS versions.

Impact of the CPU governor ?!

Three days ago I read several articles about CPU governors. On my system the “intel_pstate” driver is relevant for CPU power saving. It offers exactly two active governor modes: “powersave” and “performance” (see e.g.: https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html).

The chosen CPU governor standard for Opensuse Leap 42.2 is “powersave”.

Just for fun I repeated some simple tests for the raid array again – one time with “powersave” active on all CPU cores/threads and a second time with “performance” active on all cores/threads. The discrepancy was striking:


Test setup

HW: CPU i7 6700K, Asus Z170 Extreme 7 with Intel Sunrise Point-H Sata3 controller

Raid-Array: md-raid-10, Layout: N2, Chunk Size: 32k, bitmap: none

SSDs: 4 Samsung Evo 850

Fio parameters:

size=500m
directory=/mnt2
direct=1
ioengine=sync
bs=512k
; bs=1024k
iodepth=1
numjobs=1
[read]
rw=randread
[write]
stonewall
rw=randwrite


Test results:

Fio test case 1bs=512k, Random Read [RR] / Random Write [RW]:

Leap 42.1, Kernel 4.1:
RR: 780 MByte/sec – RW: 754 MByte/sec,
RR Spread around 35 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor powersave :
RR: 669 MByte/sec – RW: 605 MByte/sec,
RR Spread around 50 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: performance :
RR: 780 MByte/sec – RW: 750 MByte/sec,

RR Spread around 35 Mbyte/sec


Fio test case 2bs=1024k, Random Read [RR] / Random Write [RW]:

Leap 42.1, Kernel 4.1:
RR: 860 MByte/sec – RW: 800 MByte/sec
RR Spread around 30 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: powersave :
RR: 735 MByte/sec – RW: 660 MByte/sec
RR Spread > 50 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: performance :
RR: 877 MByte/sec – RW: 792 MByte/sec
RR Spread around 25 Mbyte/sec

Interpretation

The differences are so significant that one begins to worry. The data seem to indicate two points:

  • It seems that a high CPU frequency is required for optimum performance of md-raid arrays with SSDs.
  • It seems that the Leap 42.1 with kernel 4.1 reacts differently to load requests from fio test runs – with resulting CPU frequencies closer to the maximum – than Leap 42.2 with kernel 4.4 in powersave mode. This could be a matter of different CPU governors or major changes in drivers …

With md-raid arrays active, the CPU governor should react very directly to a high I/O load and a related short increase of CPU consumption. However, the md-raid-modules seem to be so well programmed that the rise in CPU load is on average below any thresholds for the “powersave”-governor to react adequately. At least on Leap 42.2 with kernel 4.4 – for whatever reasons. Maybe the time structure of I/O and CPU load is not analyzed precisely enough or there is in general no reaction to I/O. Or there is a bug in the related version of intel_pstate …

Anyway, I never saw a rise of the CPU frequency above 2300 Mhz during the tests on Leap 42.2 – but short spikes to half of the maximum frequency are quite normal on a desktop system with some applications active. Never, however, was the top level of 4200 Mhz reached. I tested also with 2000 MB to be read/written in total – then we talk already of time intervals around 3 to 4 secs for the I/O load to occur.

Questions

When reading a bit more, I got the impression, that the admins possibilities to influence the behavior of the “intel_pstate” governors are very limited. So, some questions arise directly:

  1. What is the major difference between OS Leap 42.1 with kernel 4.1 compared to Opensuse 42.2 with kernel 4.4? Does Leap 41.1 use the same CPU governor as Leap 42.2?
  2. Is the use of Intel’s standard governor mode “powersave” in general a bad choice on systems with a md-raid for SSDs?
  3. Are there any kernel or intel-pstate parameters that would change the md-raid-performance to the better again?

If somebody knows the answers, please contact me. The whole topic is also discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=191881. At least I hope so …

Addendum, 19.06.2017:
Answer to question 1 – I checked which CPU governor runs on Opensuse Leap 42.1:
It is indeed the good old (ACPI-based) “ondemand” governor – and not the “new” intel_pstate based “powersave” governor for Intel’s HWP. So, the findings
described above raise some questions regarding the behavior of the “intel_pstate based “powersave” governor vs. comparable older CPU_FREQ solutions like the “ondemand” governor: The intel_pstate “powersave” governor does not seem to support md-raid as well as the old “ondemand” governor did!

I do not want to speculate too much. It is hard to measure details of the CPU frequency changes on small timescales, and it is difficult to separate the cpu consumption of fio and the md-modules (which probably work multithreaded). But it might be that the “ondemand” governor provides on average higher CPU frequencies to the involved processes over the timescale of a fio run.

Anyway, I would recommend all system admins who use SSD-Raid-arrays under the control of mdadm to check and test for a possible performance dependency of their Raid installation on CPU governors!