Compilare il Kernel

[Gimli[2BV!2B]]

Ti direi... più RAM. 4 GiB non sono tanti se la tua attività principale non è navigazione in internet e intattenimento multimediale. Immagino UKMS dia una mano ma non credo possa fare miracoli, soprattutto in uso desktop.

Le impostazioni vm.dirty_xxx che riporti forzano scritture più frequenti possibili su disco, limitando le dimensioni dei buffer in RAM.
Riducono effettivamente il ritardo di umount di una chiavetta dopo scritture grandi?
Non so se l'intero sistema tragga benefici: molte scritture brevi che interrompono altri processi saranno effettivamente meglio di minori scritture più corpose? Hai trovato/fatto benchmark?

Io ho raggiunto la reattività ideale usando solo il BFS di Con Kolivas.
Sui vecchi pc AMD XP2000+/Pentium 4 Northwood 2.2 GHz con 1GiB di RAM mi permetteva di avere praticamente sempre compilazioni in esecuzione mentre facevo altro.

Ho montato stamattina il mio primo SSD (Samsung 840 EVO 120).
Questo il mio fstab:

/dev/sda1     /boot         ext2      noauto,noatime                              1 2
/dev/sda2     /             btrfs     noatime,ssd,compress=lzo                    0 1
/dev/sdb5     /home         ext4      noatime                                     0 2
/dev/sdb6     /usr/portage  reiserfs  noatime,nolog,notail,data=writeback         0 2
/dev/sdb7     /usr/src      ext4      noatime,data=writeback,barrier=0,commit=300 0 2
/dev/sdb8     /var          ext4      noatime                                     0 2
/dev/sdb9     none          swap      sw                                          0 0
/dev/sdc1     /mnt/archive  ext4      noatime                                     0 2

Come puoi vedere uso noatime ovunque, l'lzo come hai tu e altre cose più esoteriche in partizioni di scarsa importanza.

[Xemertix]

Non ho fatto benchmark, ma gli stalli dell'interfaccia durante il trasferimento dati su periferiche esterne sono diminuiti ma non scomparsi.

La soluzione l'ho trovata qui https://bbs.archlinux.org/viewtopic.php?id=174384

Se non erro windows scrive i dati continuamente sulla chiavetta usb, senza write cache; stavo pensando di provare a disattivarla del tutto.

Si', anche io utilizzo impostazioni simili per btrfs ovvero

# /dev/mapper/lvmpool-root
UUID=9b68e43f-c5d5-4fc5-b7d7-50b4b413a698	/         	btrfs  rw,noatime,ssd,compress=lzo,discard  0 0

Se hai un ssd dovresti usare discard per il trim.

Il mio utilizzo principale e' invece proprio la navigazione e multimedialita', ma posso arrivare ad avere decine e decine di schede aperte.

Sto valutando l'utilizzo della zswap ed eventualmente di un kernel RT, appena sistemano il bug del mancato boot sulle ultime versioni del kernel.

[Gimli[2BV!2B]]

Il discard l'ho tralasciato perché mi sono abbastanza convinto che non serva in modelli più recenti usati lasciando una buona percentuale di spazio libero.
Resta che sto usando il disco da una manciata di ore: vedrò se troverò prove che mi convincano del contrario.

zswap potrebbe starci bene.

Un kernel RT non so se potrà darti qualcosa in più, ovviamente ci sta di provare.

[Axl_Mas]

Dopo anni di BFS a questa relase visto che in diversi hanno avuto problemini volevo riprovare CFS.
Scarico i sorgenti del kernel 3.14.4, applico solamente la patch BFQ, apro con make xconfig e cerco dove attivare il CFS.....ma non lo trovo!

E' attivato in automatico oppure?

[Gimli[2BV!2B]]

È il default, comunque abilita l'opzione

General setup
 --> [*] Automatic process group scheduling

e controlla le impostazioni

Enable the block layer
 --> IO Schedulers

General setup
 --> Control Group support

Se non sbaglio dovrebbe esser tutto in quelle voci.

P.S. io non ho avuto problemi con il mio kernel patchato -gentoo-ck1

[Axl_Mas]

Rispolvero questo vecchio ma interessantissimo thread

Secondo voi ha senso aggiungere il flag "-ipo" durante la compilazione dei nostri kernel ottimizzati?
Appena ho un po' ti tempo provo e vedo di eseguire qualche benchmark.

ps: ultimamente sono passato al PDS CPU scheduler + BFQ (nel frattempo incluso officialmente nel kernel) come i/o scheduler aggiornato all'ultima patch.

[Gimli[2BV!2B]]

Non ho avuto modo di fare prove con ottimizzazioni di questo tipo per il kernel.

I vantaggi maggiori sono di riduzione di dimensione in termini di rimozione di codice duplicato. Il tutto a discapito della quantità di RAM necessaria per compilare ed ottimizzare l'intero programma in un solo, oneroso, passaggio finale.

Questa patch di Andi Kleen citata nell'articolo dovrebbe permettere di attivare queste ottimizzazioni (è necessario modificare i passaggi di compilazione, non solo aggiungere le flag).

Stando al primo link sembra sia ancora utilizzabile a gennaio 2018, e probabilmente si potrebbe riuscire ad ottenere qualcosa senza fare eccessivi salti mortali... si avranno effettivi vantaggi in un pc normale? Non so, temo possano essere molte più le instabilità introdotte o il tempo perso nel provare.