SUCCESS STORY ============= Friedrich Benad wrote: > > Hi Andi, > > Andreas Behnert wrote: > > Dann m��te man dem virtuellen Laufwerk exakt die nicht gecachten > > 64MB zuweisen. Ich kenne mich mit dem Linux-Speichermanagement nicht > > wirklich aus, habe aber das Gef�hl da� die Zuweisung ein Problem > > werden k�nnte ... > > genau das was du suchst, wurde mal von Brad Keryan als Slow-RAM-Patch > f�r 2.1.xx entwickelt (slram-Patch). > > ---schnipp--- > SLRAM, a patch that allows you to use uncached/slow memory as swap. > This can make your programs run faster because it makes sure that all > computations are run out of fast memory. It could also make your > computer slower, because it causes more swapin/outs and more disk > reads. Use at your own digression... > --schnapp-- > > Leider ist die Page von ihm nicht mehr erreichbar. > http://home.austin.rr.com/bkeryan/slram/ > bzw. nach Umleitung > http://www.terran.org/~bryan/ > > M�glicherweise ergibt eine erweiterte Google-Suche neuere Links. Auf > der LKML(-Archive) sind jedenfalls noch die alten patches zu finden. > Wie es mit dem Projekt aussieht, weis ich nicht. Scheinbar hat aber > niemand mehr seit 2.1.99 etwas dazu abgegeben :-(.
ES FUNZT! Ich habe zwar Stunden im I-Net herumgesucht, aber ES FUNZT! *freu* Mensch Fritze, wenn wir uns mal wieder sehen m�ssen wir mal ein Bier trinken gehen! Der slram-Treiber ist in die Memory Management Devices eingegangen. Das Problem ist, da� keinerlei Doku verf�gbar ist, auch nicht auf der MTD-Homepage. Aber es ist ganz einfach, wenn man nur wei� wie. Nach Stunden des Gr�belns und Suchens funzt es jetzt und zwar absolut prima: - mknod /dev/mtd0 c 90 0 - mknod /dev/mtdblock0 b 31 0 (in der devices.txt steht da zwar irgendwas mit rom0 drinnen, aber mtdblock0 pa�t schon) - CONFIG_MTD=yes, CONFIG_MTB_BLOCK=yes, CONFIG_MTB_SLRAM=yes - Kernel compilieren - /etc/lilo.conf: append="mem=64M slram=ramswap,64M,+64M" (begrenzt den Speicher auf die maximal vom i430TX cachebaren 64MB, erstellt ein bei 64MB beginnendes und 64MB gro�es, also bis 128MB reichendes mtd-Device namens ramswap, Name ist eigentlich egal) - reboot - "dmesg |grep slram" mu� erz�hlen - cat /proc/devices mu� u.a. "31 mtdblock" zeigen - "cat /proc/mtd" mu� auch erz�hlen und "ramswap" als mtd0 zeigen - mkswap /dev/mtdblock0 - swapon -p1 /dev/mtdblock0 - top sollte jetzt 64 MB mehr Swap zeigen als zuvor Um das permanent einzurichten gibt es mehrere M�glichkeiten, ich habe das z.B. so gemacht: - in /etc/fstab in der swap-Zeile "pri=1" durch "pri=2" ersetzt - in /etc/init.d/localconfig (wurde eingebunden mit "update-rc.d localconfig start 99 S .") stehen ein paar Dinge wie setleds, kbdrate und hdparm und jetzt noch zwei neue Zeilen: /sbin/mkswap /dev/mtdblock0 /sbin/swapon -p1 /dev/mtdblock0 - reboot, zuerst sollte der Swapspace der Platte eingebunden werden (Priorit�t 2), sp�ter die 64 MB RAM (Priorit�t 1) - "cat /proc/swaps" sollte entsprechendes erz�hlen Ergebnis: Die Kiste ist merklich schneller! H�tte das nie gedacht, da ja auch ein gewisser Overhead dazukommt, aber das Teil l�uft wirklich fixer. Die Prozesse, welche bei der Benutzung der gesamten 128MB teilweise bis zu 40% CPU-Last hatten, kraxeln jetzt wieder bei maximal 28% herum, wie zuvor, als nur 64MB in der Kiste steckten. Schade da� diese Funktionalit�t praktisch nicht dokumentiert ist, denn dieser slram-Treiber ist eigentlich genial! Und diese Liste hier ja sowieso! Und �berhaupt - Intel kann mich mal! Ich habe Linux! :-) Gru�, ab -- To err is human; effective mayhem requires the root password! -- -- ----------------------------------------------------------- Um sich aus der Liste auszutragen schicken Sie bitte eine E-Mail an [EMAIL PROTECTED] die im Subject "unsubscribe <deine_email_adresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ----------------------------------------------------------- 1090 eingetragene Mitglieder in dieser Liste.
