Ich habe bemerkt , heute bekannt, dass /var/log/dmesgmehrere Dutzend Zeilen mit Informationen enthält über etwas genannt gran_sizeund *BAD*gran_size, gefolgt von , was scheint mir eine Anweisung zu sein:
[ 0.000000] mtrr_cleanup: can not find optimal value
[ 0.000000] please specify mtrr_gran_size/mtrr_chunk_size
Muss ich tun, was es sagt? Wie würde ich?
MTRR steht für Memory Type Range Registers, eine neue Methode zum Partitionieren und Verwalten von Speicherressourcen in Ihrem System. Diese Funktion wurde in Prozessoren eingesetzt, da die Speichergröße immer größer wurde. Es musste eine Möglichkeit geben, den Speicher adressierter zuzuweisen und effektiver zu nutzen.
Ein Hauptmerkmal des MTRR besteht darin, Standorte von PCI- oder AGP-Komponenten in Ihrem System zuzuordnen, damit Software und Treiber schnell und effizient darauf zugreifen können.
(aus dem Gentoo Wiki )
Nach dem Lesen von Lösen von Linux-MTRR-Problemen wird der angezeigte Fehler angezeigt , wenn mtrr sanitizer nicht aus mehreren Optionen des Speicherlayouts auswählen kann. Neben der Fehlermeldung sollte eine Liste möglicher Optionen gedruckt werden. Damit die Nachricht verschwindet, müssen Sie etwas wie angeben
enable_mtrr_cleanup mtrr_spare_reg_nr=1 mtrr_gran_size=32M mtrr_chunk_size=128M
in den Kernal-Boot-Parametern (wobei die tatsächlichen Werte aus einer der vom Desinfektionsprogramm vorgeschlagenen Optionen stammen).
Der Autor des Artikels behauptet das
Jetzt sind 24 MB RAM weg, aber meine 3D-Workloads, bei denen es sich im Grunde um Webgl-Inhalte und den versteckten Flugsimulator in Google Earth handelt, laufen beide mit deutlich besseren Frameraten.
Das macht mich sehr interessiert ... muss dmesgalle meine Maschinen überprüfen .
Laut [Redhat's Knowledgebase] [1] für RHEL6, aktualisiert im Januar 2017, bedeutet "bitte mtrr_gran_size / mtrr_chunk_size angeben" :
- Diese Meldungen sind kein Problem und lediglich Warnungen. Sie können ignoriert werden.
- Durch Hinzufügen von disable_mtrr_cleanup disable_mtrr_trim zu den Kernelparametern in /boot/grub/grub.conf wird der Codepfad deaktiviert, der diese Fehler auslöst, und es kann verhindert werden, dass sie auf dem System angezeigt werden.
Ich bin mir natürlich bewusst, dass Redhat kein Ubuntu ist, aber im Großen und Ganzen laufen sie mit demselben Kernel, daher wäre ich sehr überrascht, wenn es für Ubuntu nicht dasselbe ist. Diese Antwort wird als "Zweitmeinung" angeboten.
[1]: https://access.redhat.com/solutions/2852191 - (Abonnement erforderlich)