TWEAKS per Hardware Intel

[JackDaniels]

Salve a tutti ragazzi!

Era da un po che non scrivevo su questo forum causa impegni ma nel passere dei giorni e degli anni , da quando iniziai con fedora 8 , qualcosina qua e la l’ho imparata anche se non sono assolutamente un guru.

Volevo condividere con voi alcuni accorgimenti che sembrano aver migliorato le prestazioni del sistema su hardware Intel

Iniziamo con la gestione RAM editando il file /etc/sysctl.conf
I paramentri li ho copiati da un modulo magisk di android per la gestione di RAM relativamente piccole (sono un cannibale informatico) e ho notato un risparmio di almeno 200MB e una riduzione del tempo di apertura dei programmi

vm.overcommit_ratio = 80
vm.vfs_cache_pressure = 150
vm.min_free_kbytes = 4096
vm.oom_kill_allocating_task = 0
vm.dirty_ratio = 5
vm.dirty_background_ratio = 20
kernel.random.read_wakeup_threshold = 128
kernel.random.write_wakeup_threshold = 1024

Sul versante Disco utilizzo un SSD della samsung
Ho configurato UDEV creando un file in /etc/udev/rules.d/99-ssd.rules
Anche qui ho notato un sensibile miglioramento nei tempi di avvio e in generale

SUBSYSTEM=="block", ATTRS{model}=="SAMSUNG MZMTD128*", ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="kyber"
SUBSYSTEM=="block", ATTRS{model}=="SAMSUNG MZMTD128*", ACTION=="add|change", KERNEL=="sda", ATTR{queue/read_ahead_kb}="2048"
SUBSYSTEM=="block", ATTRS{model}=="SAMSUNG MZMTD128*", ACTION=="add|change", KERNEL=="sda", ATTR{queue/rq_affinity}="0"
SUBSYSTEM=="block", ATTRS{model}=="SAMSUNG MZMTD128*", ACTION=="add|change", KERNEL=="sda", ATTR{queue/nr_requests}="512"

Sempre sul versante disco ho attivato alcuni parametri di BTRFS per gestire al meglio l’SSD editando /etc/fstab
NB autodefrag penso sia inutile su SSD

defaults,noatime,nodiratime,rw,ssd_spread,discard,space_cache,autodefrag,inode_cache,clear_cache

in fine opzione per chi usa Xorg ho creato /etc/X11/xorg.conf.d/20-intel.conf
Glamor accelera anche il 2D ergo dovrebbe rendere l’esperienza gnome piu fluida

Section "Module" 
    Load "dri3" 
    Load "glamoregl" 
EndSection 
Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"              "glamor"
    Option      "DRI"            "3"
    Option      "TripleBuffer"             "true"
EndSection

Sul versante Mesa ho disabilitato VBlack creando il file .drirc

<driconf>
  <device screen="0" driver="i965">
    <application name="Default">
   <option name="vblank_mode" value="0"/> 
</application>
  </device>
</driconf>

Infine su grub che poi dovrebbe essere l’inizio XD /etc/default/grub

GRUB_CMDLINE_LINUX="rhgb quiet i915.enable_fbc=1 i915.enable_dc=2 i915.alpha_support=1 i915.fastboot=1 i915.enable_psr=1 elevator=kyber"

Spero sia stata utile questa mia esperienza

AH DIMENTICAVO! SE ANCHE VOI AVETE DELLE CHICCHE DA SFRUTTARE , IDEE , CORREZIONI ECC VI PREGO DI INSERIRLE NEL POST COSI’ DA ARRICCHIRE LE CONOSCENZE DI TUTTI NOI LINUXARI

[fopenp]

Scommetto che tra qualche mese, quando segherò via Ubuntu dal gateway per metterci Fedora o CentOS, questa guida mi tornerà utile e proverò a seguirla… quindi grazie in anticipo!
Che hardware hai di preciso?

Unico appunto: io di solito nelle opzioni di btrfs metto principalmente cosi’ (più altre cose opzionali, come autodefrag e compress=lzo):

# per i magnetomeccanici
defaults,rw,noatime

# per gli SSD
defaults,rw,noatime,ssd,commit=180

Il nodiratime non serve quando c’è già noatime. space_cache è implicito; al massimo si può specificare space_cache=v1 o space_cache=v2.
discard avevo letto che lo sconsigliavano perchè in certi casi poteva accorciare la vita agli SSD. Al suo posto bisognere usare periodicamente il comando fstrim.
commit=180 serve per accumulare le scritture destinate all’SSD e scriverle una volta ogni 3 minuti (180 secondi). In questo modo le celle vengono stressate il meno possibile e c’è meno frammentazione.

[JackDaniels]

[quote=fopenp]Scommetto che tra qualche mese, quando segherò via Ubuntu dal gateway per metterci Fedora o CentOS, questa guida mi tornerà utile e proverò a seguirla… quindi grazie in anticipo!
Che hardware hai di preciso?

Unico appunto: io di solito nelle opzioni di btrfs metto principalmente cosi’ (più altre cose opzionali, come autodefrag e compress=lzo):

per i magnetomeccanici

defaults,rw,noatime

per gli SSD

defaults,rw,noatime,ssd,commit=180

Il nodiratime non serve quando c’è già noatime. space_cache è implicito; al massimo si può specificare space_cache=v1 o space_cache=v2.
discard avevo letto che lo sconsigliavano perchè in certi casi poteva accorciare la vita agli SSD. Al suo posto bisognere usare periodicamente il comando fstrim.
commit=180 serve per accumulare le scritture destinate all’SSD e scriverle una volta ogni 3 minuti (180 secondi). In questo modo le celle vengono stressate il meno possibile e c’è meno frammentazione.[/quote]

Grande!

Posso chiederti un favorino ino ino ino? questi accorgimenti li puoi evidenziare con BBCode come ho fatto io? cosi risaltano e non passano inosservati.

Allora sul parametro ssd di btrfs io invece ho letto il contrario (in particolare modo ssd_spread) perche permette di usare blocchi nuovi livellando il consumo generale del disco. Poi tieni presente che secondo le statistiche prima che un ssd ti molli il pc in se e’ gia un dinosauro inutilizzabile quindi questo problema non me lo pongo XD
Al contrario dicono di disabilitare autodefrag che e’ quello che usura di piu un ssd.
Per il commit=180 ovviamente i file rimarranno di piu in ram ? questo aspetto va interpolato con sysctl in modo da decidere se si vuole usare piu ram e meno disco o il contrario.
Per quanto riguarda il mio Hardware ho un tablet (si un tablet XD) con intel core i5vPro 3437U , Intel HD 4000. 4GB di RAM e un SSD della samsung da 128GB sata 3

[fopenp]

@JackDaniels

Posso chiederti un favorino ino ino ino? questi accorgimenti li puoi evidenziare con BBCode come ho fatto io? cosi risaltano e non passano inosservati.

Nessun problema… Fatto!

@JackDaniels

Poi tieni presente che secondo le statistiche prima che un ssd ti molli il pc in se e’ gia un dinosauro inutilizzabile quindi questo problema non me lo pongo XD
Al contrario dicono di disabilitare autodefrag che e’ quello che usura di piu un ssd.
Per il commit=180 ovviamente i file rimarranno di piu in ram ? questo aspetto va interpolato con sysctl in modo da decidere se si vuole usare piu ram e meno disco o il contrario.

Sì, autodefrag non lo uso più da quando uso commit=180. La commit serve per cachare in RAM le modifiche da fare sul SSD.
Sarò fatalista, ma il mio primo SSD mi è durato 20 giorni e si è guastato irreparabilmente. Quindi sicuramente sperimenterò ssd_spread, ma considerando che me la sono sempre cavata con ssd,commit=180 lascerò questi parametri per le mie unità SSD più importanti.

Grazie e ci si becca!