FreeBSD 10.0 erschienen

Moin, warum wird eigentlich converters/libiconv immer von einigen Ports benötigt (glib20), wenn libiconv zur Base gehört?

Okay.. Frage zurückgezogen, die Antwort findet sich im Makefile vom glib20-Port:

Code:
# iconv:wchar_t - our iconv in base doesn't support utf-8 -> wchar_t (boooo)
# (wchar_t is used by glibmm, rawtherapee triggered this)
 
Nur weil's mir gerade auffällt: vm.kmem_size entspricht der Größe meiner Memory. Heißt das, dass ich habe jetzt wirklich den kompletten RAM als Kernel Memory zur Verfügung und kann sie auf Routern oder sie sagen wir zum Beispiel potentiell für den pf State Table nutzen?

EDIT: Oder habe ich das nur extrem verschlafen und es ist seit FreeBSD 8 der Fall? :ugly:
EDIT: TCM's Kritik entsprechend den Artikel von Speicher geändert.
 
Zuletzt bearbeitet:
Kommt auf deine Plattform drauf an. :) vm.kmem_size gibt die Größe des virtuellen Adressraums des Kernels an. Das ist hauptsächlich der Heap des Kernel, ein Großteil alles dynamisch allozierten Speichers im Kernel liegt darin. Auf 32 Bit Plattformen ist das Problem, dass der virtuelle Adressraum sehr begrenzt ist. vm.kmem_size kann daher nur einen Bruchteil des gesamt verfügbaren Adressraums und damit heute meist auch physisch vorhandenen Speichers abdecken. Das führt grob gesagt zu zwei Problemen. Einmal zu zu wenig Speicher für speicherintensive, im Kernel laufende Anwendungen wie ZFS. Dazu unter Umständen zu einer Fragmentierung des Kernelspeichers, die früher oder später bis zur Kernelpanic degeneriert. Auf 64 Bit Plattformen hat man das Autotuning des virtuellen Adressraums des Kernel seit FreeBSD 8.0 nach und nach immer aggressiver gemacht, bis er inzwischen einen Großteil des RAMs abdeckt. Daher kannst du nun, sofern pf virtuelle Adressen nutzt, deinen Statetable tatsächlich einen Großteil des RAMs belegen lassen.
 
Da macht man mal ein paar Jährchen nichts bzw. nur wenig mit FreeBSD und verpasst alles. Danke, Yamagi. :)
 
Zurück
Oben