pierloz.com

Oggi pomeriggio ho voluto sperimentare sreadahead sull’eeepc 901.

Prima cosa da fare è stato portare la patch da ext3 a ext2, visto che sul piccolino ho scelto ext2 come filesystem per la root.

Considerato la diretta discendenza di ext3 da ext2, è stato molto semplice prendere la patch di sreadahead scritta per ext3 e crearne una per ext2.

Ho poi ricompilato il kernel (lo zen presente nel repository di robertek), ovviamente con l’aggiunta della patch appena scritta.

Ora ho sreadahead funzionante, anche se a onor del vero non vedo nessun incremento di velocità di boot (ovvero, anche senza sreadahead, sono sempre sotto i 20 secondi compreso ambiente grafico openbox+lxpanel+qualche_altra_robetta).

Mi resta da togliermi lo sfizio di guardare un bootchart, perchè stranamente bootchart non vuole funzionare.

A presto per altre osservazioni.

Eccomi a scrivere un paio di righe, ovviamente le sto scrivendo dal piccolo eeepc901 finalmente animato da una aggiornatissima archlinux

I dettagli li rimando, lascio solo un breve resoconto dell’installazione e della prima configurazione.

Partizioni Originarie

Il disco principale dell’eeepc (4 GB) si presenta partizionato in 4 partizioni. Le prime due sono utilizzate da xandros (di cui una in sola lettura). Le restanti 2 sono due piccole partizioni di circa 8 MB (mega!), una utilizzata per eventuali aggiornamenti bios (è possibile copiarci li il file del bios e al boot questo verrà aggiornato), e l’altra utilizzata per la funzione fastboot del bios.

Io ho piallato tutto eccetto l’ultima partizione, visto che il fastboot è assai splendido

Eventuali aggiornamenti del bios li farò passare da una pennetta usb.

Installazione di arch

Ho usato un masterizzatore dvd usb e l’iso di test 2008.12, per installare un sistema base.

Ho creato un’unica partizione nel disco da 4GB (eccetto quella per il fastboot) e l’ho formattata in ext2.

Niente swap.

Ho in seguito utilizzato la connessione ethernet (il modulo era già presente nel kernel) per compilare il modulo wifi (rt2860, si trova in AUR).

netcfg ha qualche problemino a funzionare. Seguendo il consiglio del wiki di arch ho optato per wicd.

Xorg funziona splendidamente senza dover scrivere nessun file di configurazione. Nota: ricordarsi di installare hal e aggiungerlo ai demoni, altrimenti xorg parte senza le periferiche di input e bisogna riavviare la macchina.

Improving it!

Tra le prime cose che ho fatto, ho montato un tmpfs in /tmp e lì ci ho fatto anche cachare (non è una brutta parola!) firefox.

Oggi ho un po giocato con i kernel di robertek, uno zen ricompilato su misura (oserei dire “striminzito”, sono 5MB) per il 901.

Installato il kernel zen-eee dal suo repo, ho installato anche acpi-eee901, che contiene gli script acpi per gestire i tasti funzione. Contiene anche il programma asusosd, che lanciato all’avvio di openbox mi da un riscontro visivo con un popup quando alzo/abbasso volume e luminosità.

Successivamente ho ricompilato il kernel zen-eee per includere un po di moduli che non so per quale motivo erano stati lasciati fuori.

A breve scrivero di qualche altro pasticcio, e di tutto quello che causa dimenticanza e fretta ho sicuramente dimenticato di dire.

Rilasciate le iso di test 2008.12

info: http://downloads.archlinux.de/iso/archboot/2008.12/

Non è una release ufficiale, sono in test, però possono tornare utili a chi serve un cd di installazione con l’ultimissimo kernel.

Negli ultimi due giorni mi sono interessato alla faccenda del famigerato boot in 5 secondi (quel famoso proof of concept uscito a settembre, per mano dell’altrettanto noto arjan… qualcuno ha detto powertop?)

Ovvero mi sono interessato a questo: http://lwn.net/SubscriberLink/299483/fa0208e48cf3eeac/

L’interesse è partito da un topic sul forum archlinux.it iniziato dal buon adriano (http://adrinux.wordpress.com/2008/12/04/boot-rapido-5-secondi-anche-su-archlinux/).

Per farla breve, fino ad adesso si è lavorato su questi due punti:

• inclusione nel kernel -ARCH della patch fastboot, che riduce il tempo di avvio del kernel facendo alcune cose in modo asincrono
• inclusione di sreadahead negli script di init di arch (rc.sysinit in particolare) e con esso anche l’integrazione della patch a ext3 per marcare i file utilizzati in fase di boot (è necessaria una root in ext3)

A giudicare dai grafici bootchart di adriano fatti su una macchina reale (io per ora sto lavorando su una macchina virtuale), sreadahead fa il suo dovere.

Il tempo di boot però non pare ridursi così tanto, anzi si notano ancora delle pause indesiderate (in particolare nella fase finale, guardate nel topic del forum i grafici).

C’è dell’altro da fare con gli script di init, quasi sicuramente.

Aggiornamenti a seguire.

Compcache serve per creare un dispositivo virtuale di swap (compresso) da mettere nella ram. E’ un modo furbo per sfruttare meglio la ram: visto che lo swap su disco è enormemente più lento, perchè non comprimere parte di ram in modo da farci stare più dati?

Ovviamente affinchè il gioco valga la candela, occorre che  il processo di compressione/decompressione dei dati sia pur sempre più veloce del corrispettivo utilizzo dello swap su disco (e normalmente ciò è vero).

Per utilizzare compcache occorre un kernel patchato (ad esempio zen), e compilato con il supporto a compcache (come modulo o statico).

Se compilato come modulo, occorrerà inserire il modulo “compcache” alla lista dei moduli in rc.conf

In fstab andrà messo il dispositivo virtuale di swap:

/dev/ramzswap0   swap             swap        pri=1,defaults         0   0

“pri=1″ serve per aumentare la priorità di questo dispositivo di swap rispetto ai restanti (in questo modo avrà la precedenza, e solo se si saturerà verrà utilizzata la partizione di swap del sistema)

Di default compcache alloca il 25% della ram.

Sul mio portatile (512 MB di ram e un disco non propriamente veloce) l’utilizzo di compcache risulta vantaggioso.

Da un paio di giorni è stato rilasciata la versione 2.6.26 del kernel linux.

A questo link il changelog “umano” redatto da Linux Kernel Newbies: http://kernelnewbies.org/LinuxChanges

Questo post per avvisare gli utenti del mio repo personale che (come forse avranno già notato) è un periodo che non aggiorno.

Ho iniziato a mettere mano al config del kernel26-zen per adattarlo alla mia specifica configurazione hardware, e allo stesso tempo ho messo mano ai flag in /etc/makepkg.conf per produrre pacchetti strettamente ottimizzati sulla mia macchina.

A questo aggiungiamo la recente difficoltà a stare dietro a tutti pacchetti dei moduli aggiuntivi (che tra l’altro nemmeno uso personalmente! a parte nvidia-beta), moduli che non sempre compilano, visto il naturale frequente aggiornamento del kernel zen (è syncato alle rc del kernel vanilla).

Ho deciso di mettere per iscritto che per ora si tratta di un semplice freeze, il repo non chiude ma rimane congelato, sperando di avere al più presto tempo e voglia di riprenderlo in mano.

Ho rimosso i pacchetti klibc-zen e v86d-zen in quanto inutili. In [core] si trovano già klibc (linkato ad un kernel compilato con uvesafb) e si trova anche v86d.

Per un certo motivo qualche ora fa mi sono trovato a dover collegare un hard disk esterno (usb) al muletto (sempre lui, muloserver).

Una volta collegato mi sono accorto che il modulo usb_storage non veniva caricato.

Considerato l’uptime della macchina (100 giorni e spiccioli) ho immaginato quale potesse essere il problema: il kernel in esecuzione - 2.6.23-ARCH - differiva dal kernel installato con pacman (ovvero kernel26) - 2.6.24-ARCH -

Effettivamente era andata proprio così: i vari aggiornamenti del pacchetto kernel26 hanno sovrascritto (com’è giusto che sia, d’altronde) i moduli del kernel correntemente in esecusione, e questo su una macchina che non viene riavviata di frequente è un bel problema, visto che la versione dei moduli installati non coincide con il kernel attivo.

Per ora ci ho messo una pezza aggiungendo

IgnorePkg = kernel26

in pacman.conf. Ovvero evito di aggiornare il kernel, cercando di aggiornarlo selettivamente solo in caso di reboot.

Se qualcun’altro avesse idee migliori, o se mi dovesse sfuggire qualcosa, sono ben accetti consigli.

Sembra che klibc abbia dei problemi con l’ultimo kernel (2.6.24).

In particolare, mi sono imbattuto in un kernel panic in fase di boot dovuto all’uso di uvesafb (e quindi v86d compilato su klibc e linkato nell’immagine di initcpio).

Se ne parla anche sul forum ufficiale di arch, e questo bug conferma l’esistenza di problemi tra klibc e il kernel 2.6.24 (http://bugs.archlinux.org/task/9482)

Di conseguenza, fino a che non sarà fixata la situazione, ho provveduto a rimuovere il supporto a uvesafb dal kernel26zen che distribuisco nel mio repo. Inoltre ora kernel26zen risulterà in conflitto con klibc-zen.