Transparent Hugepages nur mit amd64?

[Fisch.666]

Hi,

ich hatte mich in letzter Zeit etwas mit den Transparent Hugepages (THP) welche mit der version 2.6.38 in den Kernel gekommen sind auf meinen beiden Debian testing Laptops beschäftigt.

Auf einem amd64 System:

Code: Alles auswählen

Linux foo 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux

kann ich diese ohne Probleme per Kernel Parameter: transparent_hugepage=always im grub dauerhaft aktivieren und bekomme auch per:

Code: Alles auswählen

cat /proc/meminfo | grep AnonHugePages

die Anzeige dass diese auf meinem System aktiv sind:

Code: Alles auswählen

AnonHugePages:    139264 kB

Ein i386 System:

Code: Alles auswählen

Linux foo 3.9-1-686-pae #1 SMP Debian 3.9.6-1 i686 GNU/Linux

genau mit der gleichen Konfiguration will nix von den Transparent Hugepages wissen. Die /boot/config-3.9.1-686-pae enthält auch wie auf dem amd64 system die Einträge:

Code: Alles auswählen

CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

jedoch spuckt ein:

Code: Alles auswählen

cat /proc/meminfo | grep AnonHugePages

hier nur:

Code: Alles auswählen

AnonHugePages:    0 kB

aus. Auch fehlt auf dem i386 System der komplette:

Code: Alles auswählen

/sys/kernel/mm/transparent_hugepage/

Baum welcher auf dem amd64 System vorhanden ist.

Leider konnte ich bis jetzt keinerlei Infos finden ob die THPs nur auf 64bit Systemen unterstützt werden noch konnte ich herausfinden warum diese auf dem i386 System nicht aktiv sind. Hat das hier jemand so am laufen bzw. könnte das mal auf einem i386 System testen?

Vielen Dank schon einmal im voraus für eine Antwort.

[rendegast]

https://git.kernel.org/cgit/linux/kerne ... meters.txt
https://git.kernel.org/cgit/linux/kerne ... meters.txt
(kernel3.10, kernel 3.9) ->
https://git.kernel.org/cgit/linux/kerne ... nshuge.txt (viel Zeug)

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

Code: Alles auswählen

cat /sys/kernel/mm/transparent_hugepage/enabled

(In kvm-VM wheezy kernel 3.2, 64bit und 32bit bekomme ich nur enabled:never)

Vielleicht hast Du Dich beim Setzen der Option einfach verschrieben?

Code: Alles auswählen

dmesg

?

Auch fehlt auf dem i386 System der komplette:
/sys/kernel/mm/transparent_hugepage/

Dann wohl doch nicht verschrieben, oder eine Folge des Verschreibens?
Oder einfach ein testing-Bug?
<-> Eine andere Version des Kernel (aus snapshot)? experimental-kernel 3.10?

Auf einem wheezy mit wenig RAM:

Code: Alles auswählen

# cat /sys/kernel/mm/transparent_hugepage/*
always madvise [never]
always madvise [never]

Nochmal das transhuge.txt studieren?



(https://www.kernel.org/doc/Documentatio ... meters.txt
Darin ist diese Option nicht aufgeführt.)

[Fisch.666]

Hi,

vielen Dank erst einmal für Deine Antwort.

(In kvm-VM wheezy kernel 3.2, 64bit und 32bit bekomme ich nur enabled:never)

bzw.

Auf einem wheezy mit wenig RAM:

Welche Kernel-Versionen 686-pae/486 verwendest Du hier?

Code: Alles auswählen

dmesg

?

Weder in der dmesg noch in der kernel.log konnte ich hier etwas dazu finden. Ist halt auch leider schwierig wenn man nicht weiß nach welchen Fehlern man Ausschau halten muss.

Dann wohl doch nicht verschrieben, oder eine Folge des Verschreibens?

Nee, ein Schreibfehler ist es definitiv nicht. Der Kernel-Parameter ist nur dafür da die Art der Verwendung (madvise, always, never) fest zu legen. Lässt man den Kernel-Parameter weg sollte /sys/kernel/mm/transparent_hugepage/enabled auf [madvise] stehen. Hatte das extra noch mal auf dem amd64 System getestet.

Hier könntest Du für Dein System welches [never] verwendet ohne ein echo zu benutzen auf always umstellen da ja sysctl AFAIK nicht für /sys/* verwendet werden kann.

Oder einfach ein testing-Bug?
<-> Eine andere Version des Kernel (aus snapshot)? experimental-kernel 3.10?

Das Problem trat schon beim 3.2er Kernel von wheezy auf. Hatte jetzt mal auch auf den experimental 3.10er Kernel aktualisiert, dort besteht das Problem auch. Denke ich werde dann ggf. mal einen Bugreport im Bugtracker melden.

[cosmac]

Code: Alles auswählen

grep pse /proc/cpuinfo | uniq

nicht, dass die Hardware das garnicht hergibt...

laut http://wiki.debian.org/Hugepages

[Fisch.666]

Arghhhs, natürlich. An die Hardware hab ich absolut nicht gedacht.

Das i386 System hat nen Atom N270 verbaut welcher lt. /proc/cpuinfo keine pse flag hat. Ich hab zwar paar Foreneinträgen von Usern mit der gleichen CPU gesehen die in ihrem cpuinfo Output ne pse flag hatten, aber vielleicht ist das doch ne spätere Version der gleichen CPU.

Denke damit hat sich das Thema hier erledigt und wir haben den Übeltäter.

Vielen Dank für Eure Hilfe!

*Edit*

Ok, noch kurz gesucht und den Grund gefunden warum manche User die pse flag haben:

http://blog.jolexa.net/2011/01/updating ... mment-4736

Der Kernel deaktiviert PSE wohl wegen einem Bug in der CPU und trotz verwendeten micrcode-update, welches erst zu spät geladen wird bleibt PSE deaktiviert. Das könnte man zwar direkt über ein BIOS-Update beheben, für mein Mainboard gibt es jedoch kein aktuelleres.

[cosmac]

in dem Blog wird aber auch ein Trick mit kexec erwähnt; dafür sollte dir der aktuelle Microcode reichen.

kexec for bootloader!

[Fisch.666]

Hi,

den hatte ich mir heute erst durchgelesen. Die Lösung über kexec war mir jedoch zu heikel, da der microcode nach einem hibernate wohl nicht mehr im Kernel geladen ist.

Der 3.9er Kernel unterstützt jedoch so genannte "early microcode updates":

https://git.kernel.org/cgit/linux/kerne ... ags/v3.9.9

welche schon im intel-microcode Paket Version 1.20130222.3 unterstützt werden. Jetzt reicht ein einfaches setzen von:

IUCODE_TOOL_INITRAMFS=early

in der /etc/default/intel-microcode und ein Updaten des initramfs images und die THP sind auf dem i386 System aktiviert.