Compilare il Kernel

[Gimli[2BV!2B]]

Originariamente inviato da LinuxOs

tutte ste nuove voci che vengono aggiunte di release in release e delle quali a volte non esiste una descrizione delle caratteristiche, mandano non poco in confusione sulle scelte da fare nella compilazione di ogni nuovo kernel.

Non sono molto d'accordo su questa affermazione.
Ad ogni avanzamento di versione spesso sono effettivamente presenti anche un 10÷20 o più voci nuove, ma non mi sono mai trovato di fronte qualcosa che fosse assolutamente criptico.
La maggioranza è costituita da driver per nuove periferiche, il restante è spesso proposto con la scelta più adatta per un utente finale e con una breve descrizione che è spesso sufficiente per inquadrarne lo scopo. In caso di dubbi una ricerca in Goggle dà solitamente tutti i chiarimenti necessari.

Quello con cui ti stai misurando e che stai cercando di automatizzare è il primo impatto con tutte le voci disponibili.
Come dice darkbasic non è un gran problema rintracciare i driver che ti servono, ma ti trovi di fronte ad una grande quantità di altre impostazioni da analizzare ed adattare alle tue necessità ed al tuo hardware.

Una volta creata una configurazione completa, ciò che richiede più tempo, sarà molto più semplice aggiornarla di versione in versione o utilizzarla come base per macchine con hardware diverso ma scopi simili.

Con Kolivas ha appena scritto che ci vorranno alcuni giorni perché non si aspettava il 38 così presto, dove hai letto che ha finito?
Se si tratta di una notizia di un porting di terzi sarei anche ben contento di provarlo comunque, il goup scheduling non mi soddisfa...

[pabloski]

Originariamente inviato da Gimli[2BV!2B]

il goup scheduling non mi soddisfa...

notizia preoccupante

non ti soddisfa nel senso che non mantiene le promesse?

[Gimli[2BV!2B]]

L'ho già accennato qualche post fa: il sistema rimane utilizzabile anche con cpu al 100% ma si subiscono comunque sporadici ritardi.
Inoltre se si lancia un altro processo un minimo intenso il mio single core si deve arrendere.
Con il BFS di ck il sistema rimane molto utilizzabile anche caricandolo abbondantemente (per esempio si vede bene un filmato flash anche durante una compilazione, mentre con il group scheduling va molto più a scatti).

I kernel precedenti erano senz'altro molto meno interattivi in caso di sistema carico, ma non si raggiunge l'eccellenza dello scheduler "estremista" di ck.
Ricordo che sto usando un PIV 2.2, quindi risulto abbastanza sensibile alle capacità dello scheduler, probabilmente usando un pc moderno la differenza percepibile potrebbe essere minore.

[Gimli[2BV!2B]]

Ho dato un'occhiata al seme per kernel vanilla di kernel-seeds per i386.
Osservazioni che mi ha suscitato.

PRO

• Si tratta di una configurazione generica, completamente priva di driver per specifiche periferiche.
• Trovo condivisibili buona parte delle scelte relative alle voci non di driver: adatte ad un sistema multicore moderno.

CONTRO

• Occorre comunque spulciarla quasi completamente per poterla utilizzare.
• Inadatta per macchine che non siano un classico pc desktop.
• Conservativa: ha attive opzioni che permettono compatibiltà con software stagionato.
• Audio completamente inattivo: né ALSA né OSS.
• Niente Ext4?!
• Porzioni di debug attivo.
• Tutte le Library routines e le Cryptographic API attive ed integrate.
• Wireless disattivata, non è una cosa immediata destreggiarsi nell'attivazione.

Non sono riuscito ancora a vedere la documentazione perché mi risulta spesso irraggiungibile.
Personalmente quando trovo un'opzione oscura la cerco in Google, prediligendo i risultati KernelTrap ed articoli come questi di The H.

Su Arch non faccio il guastafeste, la considero una distribuzione interessante.

Il BFQ quasi quasi lo provo: il disco l'ho sempre trascurato, magari ottengo un miglioramento.

P.S. non guardare solo la dimensione della vmlinuz: lsmod che dice? E dmesg | grep -e "Memory\|Freeing"
Per finire i moduli: du -sh /lib/modules/$(uname -r)/

[Gimli[2BV!2B]]

Per la gioia di grandi e piccini, 2.6.38-ck1!

Confermo che la differenze è percettibile sul mio single core, non enorme ma apprezzabile.

[Gimli[2BV!2B]]

Correggo, la differenza si nota eccome: vado alla console per lanciare la compilazione del kernel patchato con BFQ (suggerito da LinuxOs) e mi rendo conto che ha quasi finito.

Nel frattempo ho navigato, pasticciato con la collezione musicale in Amarok, visto filmatini Flash e aperto Eclipse dimenticandomi della compilazione...

[Axl_Mas]

Originariamente inviato da LinuxOs

Patch BFQ (disk scheduling) e Patch BFS (cpu scheduling) eseguite con successo

Il BFS lo uso da quando è uscita la prima versione, questo BFQ non lo conoscevo ma facendo una ricerchina sembra che dia davvero un grosso aumento delle prestazioni del disco!!!

Che mi dite a riguardo del bfq?Ha qualche controindicazione/problema o solo effetti benefici?

E un'ultima domanda: che differenza c'è tra la semplice patch bfs e la ck1?

[darkbasic]

Originariamente inviato da Axl_Mas

Che mi dite a riguardo del bfq?Ha qualche controindicazione/problema o solo effetti benefici?

Quando si parla di scheduler le controindicazioni ci sono SEMPRE

[Axl_Mas]

Originariamente inviato da darkbasic

Quando si parla di scheduler le controindicazioni ci sono SEMPRE

Nello specifico del bfq?

[Gimli[2BV!2B]]

Il BFQ (Budget Fair Queueing) è stato scritto con scopi simili al BFS: ridurre la latenza del sistema distribuendo le risorse in modo prioritario ai programmi interattivi, lasciando in secondo piano processi che cercano di accaparrarsi tutte le risorse disponibili.

Lo scheduler di I/O standard del kernel, il CFQ (Completely Fair Queuing) ha alla sua base un concetto di questo tipo: code di processi che richiedono accesso al disco a cui viene dato pieno accesso per fette di tempo fisse, a rotazione (pesati in base ad eventuali priorità impostate).
Anche in caso di processi con priorità bassa questi potrebbero accaparrarsi la maggior parte delle risorse impantanando il sistema.

Il BFQ invece analizza il comportamento dei processi, determinando quali tendono a fare troppe richieste. La priorità di questi viene ridotta automaticamente, permettendo al sistema di portare a termine nel minor tempo possibile brevi richieste di accesso al disco anche quando la risorsa è pesantemente sfruttata.
Le richieste brevi sono solitamente fatte da programmi interattivi, il risultato dovrebbe essere quindi una riduzione della latenza ed una maggiore efficienza del flusso di dati da e verso le periferiche di archiviazione.
Il Group Scheduling devo ancora analizzarlo.

Questo scheduler dovrebbe essere quindi consigliabile per macchine tese ad utilizzo interattivo.
Per contro sul sito viene riportato che, pur derivando dal CFQ, non sono state reimportate alcune modifiche introdotte in questo scheduler dal momento del "fork" in poi, come failsafe queue allocation, simplified dispatch cycle (una veloce ricerca non mi ha illuminato su queste due feature), ottimizzazioni per SSD, ecc...

Come ho scritto lo sto provando per la prima volta, l'attuale impressione è che il miglioramento non sia percepibile come con il BFS, anche perché, solitamente, non stresso particolarmente il disco durante il mio utilizzo normale del pc.

[Axl_Mas]

Grazie Gimli per la risposta davvero professionale!!

[Axl_Mas]

Sono andato a scaricare la pathc bfq ma ho trovato 3 patch
http://algo.ing.unimo.it/people/paol...ed/sources.php

Devo scaricare e applicare tutte e 3 o solo una?Se si quale?

[EDIT] Ho trovato, devo installarle tutte e 3

[Gimli[2BV!2B]]

Da quando ho usato Gentoo ho smesso (pigrizia...) di usare make-kpkg.
Il classico make install si ostina a crearmi una initrd.img nonostante non me ne importi nulla; ho spulciato il makefile e cercato qua e là ma non son riuscito a capire come spiegargli che non la voglio.

Suggerimenti? Ora la elimino manualmente subito dopo l'installazione, ma preferirei evitare di crearla.

[ezln]

Originariamente inviato da Gimli[2BV!2B]

Da quando ho usato Gentoo ho smesso (pigrizia...) di usare make-kpkg.
Il classico make install si ostina a crearmi una initrd.img nonostante non me ne importi nulla; ho spulciato il makefile e cercato qua e là ma non son riuscito a capire come spiegargli che non la voglio.

Suggerimenti? Ora la elimino manualmente subito dopo l'installazione, ma preferirei evitare di crearla.

Ciao, Gimli. Io pensavo che fosse la regola avere un'initrd.img. Tanto che su gentoo, tempo fa, non mi veniva creata e 'sto fatto non mi piaceva...

[Gimli[2BV!2B]]

Ciao ezln. L'initrd non è indispensabile, praticamente è un contenitore di moduli e firmware che potrebbero servire prima che la partizione root sia montata.
Se si integrano i moduli necessari per montare la root (driver controller SATA/IDE e filesystem) e non si hanno necessità software oppure hardware particolare se ne può fare a meno.

[ezln]

Originariamente inviato da Gimli[2BV!2B]

Ciao ezln. L'initrd non è indispensabile, praticamente è un contenitore di moduli e firmware che potrebbero servire prima che la partizione root sia montata.
Se si integrano i moduli necessari per montare la root (driver controller SATA/IDE e filesystem) e non si hanno necessità software oppure hardware particolare se ne può fare a meno.

Grazie per la risposta, impeccabile come al solito.

[Gimli[2BV!2B]]

Da una settimana 3.3.1-ck1, ed ho ricominciato ad usare make-kpkg.

wget http://ck.kolivas.org/patches/3.0/3.3/3.3-ck1/3.3-ck1-broken-out.tar.bz2
rm -R patches
tar xjf 3.3-ck1-broken-out.tar.bz2
patch -p1 -d linux-3.3 < patches/3.3-sched-bfs-420.patch
patch -p1 -d linux-3.3 < patches/kconfig-expose_vmsplit_option.patch
patch -p1 -d linux-3.3 < patches/hz-default_1000.patch
patch -p1 -d linux-3.3 < patches/hz-no_default_250.patch
patch -p1 -d linux-3.3 < patches/hz-raise_max.patch
patch -p1 -d linux-3.3 < patches/preempt-desktop-tune.patch
patch -p1 -d linux-3.3 < patches/ck1-version.patch
wget http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.3.1.xz
patch -p1 -d linux-3.3 < <(xzcat patch-3.3.1.xz)
mv linux-3.3 linux-3.3.1-ck1
cp linux-3.2-ck1/.config linux-3.3.1-ck1/
cd linux-3.3.1-ck1
make oldconfig
make menuconfig
fakeroot make-kpkg --append-to-version "-kwankey" --revision 1 kernel_image kernel_headers

Mi ero disabituato, ma in Debian e famiglia è molto meglio usare make-kpkg.
A parte la questione initrd, toglie vari passaggi e crea un pacchetto con nome di versione allineato a quelli standard. Inoltre il pacchetto invoca tutti i processi pre-install, post-install sistemando Grub, dkms, ecc...
Per non parlare della comoda pulizia col purge dei pacchetti obsoleti.

Restava giusto un problema: i symlink in /lib/modules del kernel installato finivano per puntare alla cartella in cui si era fatta la compilazione.
Questo creava fastidi se si cancellava o rinomina quella cartella prima della disinstallazione del relativo kernel.
Però, solitamente, si crea anche un bel pacchetto di headers compatto e stabile, perché non usare quelli, come nei kernel da repository?

gimli@kwankey:~$ cat /etc/kernel/header_postinst.d/symlinks
#!/bin/bash

# We're passed the version of the kernel being installed
inst_kern=$1

uname_s=$(uname -s)

_get_build_dir() {
    KVER=$1
    case ${uname_s} in
       Linux)          DIR="/lib/modules/$KVER/build" ;;
    esac
    echo $DIR
}

_get_source_dir() {
    KVER=$1
    case ${uname_s} in
       Linux)          DIR="/lib/modules/$KVER/source" ;;
    esac
    echo $DIR
}

_get_headers_dir() {
    KHDRS=$1
    case ${uname_s} in
       Linux)          DIR="/usr/src/$KHDRS" ;;
    esac
    echo $DIR
}

case "${uname_s}" in
    Linux)
        header_pkg="linux-headers-$inst_kern"
        kernel="Linux"
    ;;
esac

DIR_BUILD=$(_get_build_dir $inst_kern )
DIR_SOURCE=$(_get_source_dir $inst_kern )
DIR_HEADERS=$(_get_headers_dir $header_pkg )

if [ -h "$DIR_BUILD" -a -d "$DIR_HEADERS" ] ; then
    rm "$DIR_BUILD"
    ln -s "$DIR_HEADERS" "$DIR_BUILD"
fi

if [ -h "$DIR_SOURCE" -a -d "$DIR_HEADERS" ] ; then
    rm "$DIR_SOURCE"
    ln -s "$DIR_HEADERS" "$DIR_SOURCE"
fi

L'ho scritto ora e testato una sola volta, mi sembra sicuro e corretto, ma lo ricontrollerò.

[Gimli[2BV!2B]]

Probabilmente CK rilascerà la patch per il kernel 3.4 con un po' di ritardo.
Se qualcuno fosse interessato ad utilizzare la patch per 3.3 con le minime correzioni necessarie per farla funzionare sul 3.4, senza garanzie sul risultato posso riportare le poche modifiche necessarie.
L'ho utilizzata intensamente su un solo sistema 32bit single core per qualche giorno dove non ha evidenziato errori o comportamenti anomali.

Linux kwankey 3.4.0-ck1-kwankey #3 PREEMPT Sun May 27 17:51:34 CEST 2012 i686 GNU/Linux

[Axl_Mas]

Originariamente inviato da Gimli[2BV!2B]

Probabilmente CK rilascerà la patch per il kernel 3.4 con un po' di ritardo.
Se qualcuno fosse interessato ad utilizzare la patch per 3.3 con le minime correzioni necessarie per farla funzionare sul 3.4, senza garanzie sul risultato posso riportare le poche modifiche necessarie.
L'ho utilizzata intensamente su un solo sistema 32bit single core per qualche giorno dove non ha evidenziato errori o comportamenti anomali.

Linux kwankey 3.4.0-ck1-kwankey #3 PREEMPT Sun May 27 17:51:34 CEST 2012 i686 GNU/Linux

Sono interessato e pronto a testare la patch su un turionII e lubuntu 64 bit...in attesa della patch ufficiale, anche se ck sembra molto impegnato ultimamente nella vita reale.

[Gimli[2BV!2B]]

Sottolineo nuovamente che non ho le competenze necessarie ed ho solamente corretto le poche incompatibilità emerse analizzando le modifiche apportate nel kernel vanilla, quindi sii conscio che potrebbe darti problemi.

--- linux-3.4/kernel/sched/bfs.c	2012-05-30 22:38:17.190879529 +0200
+++ linux-3.4-ck1/kernel/sched/bfs.c	2012-05-27 17:35:27.044951773 +0200
@@ -69,6 +69,7 @@
 #include <linux/slab.h>
 #include <linux/init_task.h>
 
+#include <asm/switch_to.h>
 #include <asm/tlb.h>
 #include <asm/unistd.h>
 #include <asm/mutex.h>
@@ -3213,7 +3214,7 @@ need_resched:
 	 */
 	if (unlikely(deactivate && blk_needs_flush_plug(prev))) {
 		grq_unlock_irq();
-		preempt_enable_no_resched();
+		sched_preempt_enable_no_resched();
 		blk_schedule_flush_plug(prev);
 		goto need_resched;
 	}
@@ -3299,12 +3300,24 @@ need_resched:
 		grq_unlock_irq();
 
 rerun_prev_unlocked:
-	preempt_enable_no_resched();
+	sched_preempt_enable_no_resched();
 	if (unlikely(need_resched()))
 		goto need_resched;
 }
 EXPORT_SYMBOL(schedule);
 
+/**
+ * schedule_preempt_disabled - called with preemption disabled
+ *
+ * Returns with preemption disabled. Note: preempt_count must be 1
+ */
+void __sched schedule_preempt_disabled(void)
+{
+  sched_preempt_enable_no_resched();
+  schedule();
+  preempt_disable();
+}
+
 #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
 
 static inline bool owner_running(struct mutex *lock, struct task_struct *owner)
@@ -3463,9 +3476,9 @@ EXPORT_SYMBOL(__wake_up);
 /*
  * Same as __wake_up but called with the spinlock in wait_queue_head_t held.
  */
-void __wake_up_locked(wait_queue_head_t *q, unsigned int mode)
+void __wake_up_locked(wait_queue_head_t *q, unsigned int mode, int nr)
 {
-	__wake_up_common(q, mode, 1, 0, NULL);
+	__wake_up_common(q, mode, nr, 0, NULL);
 }
 EXPORT_SYMBOL_GPL(__wake_up_locked);
 
@@ -4576,7 +4589,7 @@ SYSCALL_DEFINE0(sched_yield)
 	__release(grq.lock);
 	spin_release(&grq.lock.dep_map, 1, _THIS_IP_);
 	do_raw_spin_unlock(&grq.lock);
-	preempt_enable_no_resched();
+	sched_preempt_enable_no_resched();
 
 	schedule();

Ho utilizzato le seguenti patch dell'insieme ck1:

1. 3.3-sched-bfs-420.patch
2. hz-default_1000.patch
3. hz-no_default_250.patch
4. hz-raise_max.patch
5. preempt-desktop-tune.patch
6. ck1-version.patch

Si applicano tutte con qualche offset.
Alla fine ho applicato le modifiche riportate al solo (importante) file kernel/sched/bfs.c, sul modello delle novità bell'originale kernel/sched/core.c