[RISOLTO] Metà CPU usata durante compilazione con emerge

[randomaze]

[silvius]

[.:deadhead:.]

forse è meglio uscire da kde anzichè killarli brutalmente...
_________________
Proudly member of the Gentoo Documentation Project: the Italian Conspiracy !

[silvius]

[Dece]

[silvius]

[randomaze]

[.:deadhead:.]

beh può esser un'esperienza, come giocare a psDoom o a Brutal File Manager
_________________
Proudly member of the Gentoo Documentation Project: the Italian Conspiracy !

[silvius]

Ho fatto un pò di prove e ho migliorato i tempi di compilazione togliendo i vari demoni *cpufreq..

Cambiando a mano i valori di frequenza e tipo governor, ho sempre il problema che se lancia un applicativo ( ad es. glxgears ) uso solo una cpu cioè:

Lancio glxgears, e
CPU0=0% e CPU1=100%

dopo qualche secondo

CPU0=50% e CPU1=50%

e dopo ancora pochi secondi

CPU0=100% e CPU1=0%

In sostanza continuano a cambiare ma non arrivano mai entrambi al 100%.
Se lancio un' altra applicazione o semplicemente muovo una finestra nel desktop allora entranbe vanno al 100%

E' un problema di scheduler ?


Saluto

[.:chrome:.]

[silvius]

[randomaze]

[.:chrome:.]

esiste, oltre a make.conf, anche make.conf.example che è ampiamente commentato:

[!equilibrium]

[kueitao]

Perché qualcuno pensa che l'utilizzo della CPU prossimo al 100% sia una buona cosa e da ricercarsi attentamente???

In effetti è al contrario. Mi spiego meglio, senza comunque avere la pretesa di poter riassumere anni di studio delle architetture di processori e dei sistemi operativi in poche righe.

Le CPU moderne operano a frequenze molto alte e spesso terminano il lavoro assegnato prima che il sistema abbia fatto in tempo a fornirle di nuovi dati. In sintesi rimangono bloccate in attesa di eventi di I/O. Anche il semplice accesso alla RAM è almeno una decina di volte più lento di quello ad una cache L1 e di almeno 4-5 volte rispetto alla cache L2 (se presente). Ovviamente i valori precisi dipendono da processore, chipset e tecnologia della RAM.

Infatti una delle caratteristiche più importanti di una CPU è oggi la capacità di predire le future necessità di dati e istruzioni e quindi di far in modo che il sistema li ricerchi e li metta a disposizione mentre ancora sta operando su quelli precedenti. Purtroppo gli algoritmi di "prediction" devono anche essere aiutati dalla capacità del compilatore di segnalare percorsi probabili e meno probabili, dalla qualità del codice emmesso (sempre dal compilatore-assemblatore) e anche dalla qualità del codice sorgente scritto dal programmatore e dagli strumenti di programmazioni offerti dal binomio linguaggio-compilatore.

Se lo scheduler del sistema operativo è ben progettato ed impementato (come quello di Linux), appena un processo è bloccato in attesa dei suddetti eventi di I/O (input/output), questo viene posto in una "coda di attesa". Se presenti altri processi che possono invece utilizzare in quel momento la capacità di calcolo della CPU tra questi sarà scelto quello con la più alta priorità dinamica per essere assegnato alla CPU al momento libera.

Se gli eventuali altri processi, attivati uno per volta, terminano velocemente la loro esecuzione e il primo processo che era in attesa dell'evento di I/O sta ancora aspettando è ovvio che la CPU non potrà in nessun modo essere utilizzata fino al 100%

fabio de francesco

[.:chrome:.]

[kueitao]

Ah, dimenticavo... I processi che "ps aux" descrive all'interno delle parentesi quadre, come [khelper] , [events] e diversi altri sono i cosidetti "kernel threads" e NON devono assolutamente essere terminati. Nel migliore dei casi il kernel li re-inizializza la prima volta che ne ha bisogno, ma nel peggiore...

fabio

[kueitao]

In questo thread si sono trattati diversi temi relativi all'utilizzo delle CPU, ai meccanismi del Linux Scheduler e al Multi-Threading. Dalla mia peraltro sporadica lettura dei post di questo forum mi pare di aver notato che spesso viene fuori qualcuno che non è contento, o sospetta qualche malfunzionamento, della gestione delle risorse da parte del Kernel Linux.

Con il precedente post spero di aver almeno contribuito a gettare un po' di luce sul falso problema della percentuale di utilizzo delle CPU. Vorrei ora spendere qualche riga a proposito del tema della esecuzione parallela dei processi e dei loro eventuali diversi thread.

C'è chi pensa di poter fare un miglior lavoro di distribuzione del carico sulle diverse CPU, reali (SMP) o virtuali (Hyperthreading) che siano, rispetto a quanto il Load Balancer (sottosistema dello Scheduler preposto al controllo e alla efficiente distribuzione dei threads su più processori) sia in grado di operare, quindi è alla ricerca di eventuali utility che egli possa utilizzare per inviare GCC alla prima CPU, Mozilla alla seconda, OpenOffice alla terza e così via.

Su Linux esiste la possibilità di operare per modificare in diversi modi il funzionamento dello Scheduler ed in particolare esiste un meccanismo per eseguire certi processi solo su una o più CPU escludendo le rimanenti. In pratica su un sistema doppio processore si potrebbe essere in grado di spedire un processo ad eseguire sulla CPU 0 e un altro sulla CPU 1. Le utility che permettono questo intervento da riga di comando agiscono tutte attraverso la system call "sched_setaffinity(2)". Al momento non ricordo il nome di una utility precisa ma è banale per un programmatore su GNU/Linux costruirne una con poche righe di C o C++ che invochino la suddetta syscall. (Se nel frattempo mi ricordo il nome della utility lo aggiungo in un post scriptum).

Quindi si può fare e in definitiva si fa. Però fermi la! Nessun saggio amministratore di sistema userebbe la detta utility solo sulla base di una sua percezione non scientificamente provata da ore ed ore di profiling (rilevamento di valori chiave di utilizzo di risorse nel tempo) e successiva analisi dei valori registrati. Senza scendere in particolari troppo tecnici è senz'altro errato immaginare a priori ad esempio che se forzo l'utilizzo della CPU 0 per tutti i miei lavori di compilazione (emerge -uD world) mentre invece spedisco il lettore del CD-ROM audio per l'esecuzione dei miei brani preferiti sulla CPU 1 io possa ottenere un qualche minimo miglioramento.

Nè tantomeno funzionano ragionamenti simili fin troppo spesso riportati dai thread di questo ed altri forum. Lo scheduler ed il suo load balancer fanno dei calcoli molto complessi ed accurati per decidere quale processo esegue su quale CPU. Tanto per citare un esempio spesso portato avanti da certi utenti per tentare di dimostrare che il Load Balancer non stia facendo un buon lavoro c'è il (falso) problema citato da chi per caso scopre che in una macchina con CPU Hyperthreaded due thread stanno eseguendo sulla prima CPU virtuale mentre le seconda è idle (non occupata).

A questo proposito si sappia che due diversi thread spesso condividono lo stesso codice e gli stessi dati (sia in lettura che in scrittura). Quindi è assolutamente possibile che il Kernel decida di farli eseguire sulla stessa CPU lasciando la seconda senza nessun carico importante perché la penalizzazione dovuta alla mancata esecuzione parallela e di molto compensata dai diversi vantaggi. In questa situazione (1) il sistema non necessiterà di operare il trasferimento del thread ad altra CPU, che di per sè ha un overhead importante soprattutto rispetto ai tempi di esecuzione di codice applicativo molto breve, poi (2) non saranno necessari continui aggiornamenti di RAM e Cache L1 ed L2 (se non condivise) da un processore all'altro per mantenere la consistenza dei dati (nel citato caso di condivisione di dati inter-thread), (3) ci sono meno operazioni Kernel da effettuare per conto del/dei processo/i quando tutti i thread eseguono sulla stessa CPU.

In conclusione, chi è interessato a vedere che succede sperimenti pure con trasferimenti di processi tra CPU perché di fatto non può danneggiare niente. Scoprirete che nella quasi totalità dei casi riuscirete solo a peggiorare la responsività del sistema.

La system call che citavo sopra, oltre alle altre sue sorelle tutte chiamate "sched_*", hanno comunque motivo di esistere e hanno importanti destinazioni di utilizzo. Al momento me ne vengono in mente un paio.

(1) Su sistemi server con parecchi processori (direi oltre i quattro o anche otto) utilizzati sempre allo stesso modo e con lo stesso mix di applicazioni e dati, magari l'amministratore ha studiato studiato a tavolino, a seguito di profiling e analisi di statistiche, una certa combinazione statica che in quello specifico caso non è calcolabile e verificabile in automatico dagli algoritmi dello Scheduler che ricordo essere abbastanza generalizzati per operare efficientemente su macchine e carichi di lavoro molto diversi tra loro.

(2) Gli stessi Linux Developers usano questi meccanismi durante lo sviluppo per testare il corretto funzionamento del codice anche sotto carichi di lavoro estremi ed inusali e così assicurare agli utenti stabilità ed efficienza.

(3) Nonostante tutto non crediate che il Load Balancer del Linux Kernel sia perfetto ed adatto a tutte le occasioni. E' ottimo ma perfettibile e nel frattempo può rivelarsi necessario che l'azione dell'uomo pensante intervenga per regolarne i meccanismi manualmente. Per dire tutta la verità è già stato provato che in determinate specifiche e rare situazioni qualcosa non funziona a dovere nella distribuzione dei carichi di lavoro tra le CPU. Credo di dover discutere almeno brevemente un certo problema a cui peraltro è stata già fornita una soluzione.

Sotto determinate condizioni, ripeto molto rare, purtroppo può accadere che ad esempio una macchina bi-processore si ritrovi con due processi o thread ad alta priorità (nice -20) su CPU 0 e due thread a bassa priorità (nice +20) su CPU 1. Il risultato è che i due processi a bassa priorità di esecuzione finiscono per avere esattamente il 50% del tempo della CPU 1 come i due processi ad alta priorità anch'essi con il 50% ciascuno del tempo della CPU 0. Si capisce che in questo modo tutti e quattro i processi/thread finiscono per funzionare come se avessero la stessa priorità e forniscono così un comportamento inaspettato. Ecco un buon motivo per intervenire manualmente, almeno finché il bug logico non sarà risolto.

Come dicevo una soluzione possibile è stata presentata sulla LKML quasi due mesi fa. Siccome non sono aggiornato da più o meno quella data in cui si prospettava l'inclusione delle patch sulla allora futura release 2.6.18 non so se realmente ciò è avvenuto. Tra l'altro non so neanche se la release 2.6.18 è già stata ufficialmente rilasciata.

In ogni caso a breve anche il suddetto problema sarà risolto e anche la quasi totalità dei rarissimi motivi che necessitano dell'intervento manuale saranno faccende superate... Ah... Ora ricordo! Per chiunque fosse interessato a giocare con i processi e le CPU da riga di comando esiste la utility "taskset" (emerge sys-process/schedutils), creata apposta proprio per utilizzare le suddette syscalls per accoppiare processi a CPUs.

Buon divertimento.

fabio de francesco

[silvius]

[randomaze]

[silvius]

[kueitao]

Caro Silvius,

Come Randomaze ha sottolineato, e come io stesso avevo avvertito all'inizio di una mia risposta, le tue domande meriterebbero l'apertura di un intero corso di studi universitari o almeno di quattro o cinque materie d'esame diverse. Tra queste sicuramente Sistemi Elettronici, dal I al III, Sistemi Operativi e Programmazione (preferibilmente proprio in C e/o C++ su UNIX-GNU/Linux).

Speravo di aver fatto almeno un minimo di luce, però vedo che hai letto TROPPO velocemente e perdendoti i dettagli, con il risultato di giungere a conclusioni spesso errate. Sembra che non riesci ad afferrare come determinate soluzioni sono adatte a certi contesti mentre altre lo sono meno pur rimanendo ottime per altri contesti ancora.

Se avessi letto bene il mio precedente intervento non avresti posto alcune delle successive domande... Comunque, visto che si tratta di FAQ che ritornano SEMPRE, voglio spendere ancora qualche minuto per fornire almeno qualche risposta lampo...

Un avvertimento prima di proseguire: nel discorso non si vuole DI PROPOSITO scendere al livello delle diverse forme di implementazione di "processi" e "thread" da parte del kernel. Avrete sentito dire che su Linux si tratta sempre di processi separati che al limite condividono alcune risorse. Nel discorso che stiamo facendo questo aspetto tecnico NON è assolutamente rilevante, se non a proposito dei tempi impiegati dal kernel a "costruire" un nuovo processo oppure un nuovo thread. Questi tempi più o meno si EQUIVALGONO, quindi questo parametro NON deve mai essere tenuto in conto nello scegliere tra processi e threads.

[kueitao]

Ah, ecco trovato un altro thread simile a questo dal titolo "Dividere il carico tra le CPU", dove comunque non ho approfondito come in questo caso.

https://forums.gentoo.org/viewtopic-t-436105.html

[randomaze]

Ho splittato la parte dove discutiamo del sito di faq in questo thread
_________________
Ciao da me!