# [RISOLTO] Metà CPU usata durante compilazione con emerge

## Gr3yFox

Premetto che sono nuovo di questo forum, quindi saluto tutti.

Ho un sistema Athlon64 X2 che ho configurato con le safe flags in CXFLAGS e con "-j3" come serve per i dual core, inoltre ho compilato il kernel con il supporto multiprocessore.

Ho lanciato l'emerge del nuovo Xorg ma il processore risulta impegnato solo a metà, quindi deduco che venga utilizzato un solo core.

E' possibile far si che vengano usati entrambi i core durante gli emerge? Oppure potrei aver sbagliato qualcosa io nella configurazione?

Grazie mille.

----------

## .:chrome:.

da cosa deduci questo?

in ogni caso, a prescindere dalla correttezza della tua deduzione, come i processi vengono distribuiti tra i processori è una decisione dello scheduler, che deve essere opportunamente istruito.

prova a fornire qualche informazione in più

----------

## Gr3yFox

Deduco che non vengano usati entrambi dal fatto che l'utilizzo del processore risulta al massimo del 50% anzichè del 100% (lanciando emerge soltanto, senza altri processi attivi)

Ecco qualche informazione di più:

qui c'è il mio make.conf:

```
CFLAGS="-march=k8 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

MAKEOPTS="-j3"

CXXFLAGS="${CFLAGS}"

USE="X alsa aac avi cdr dvd dvdr icq msn pdflibs usb amd64 xmms xv xvid win32codecs vcd 4vl jpeg gif -kde cups foomaticdb ppds symlink"

GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ ftp://ftp.unina.it/pub/linux/distributions/gentoo http://mirror.switch.ch/ftp/mirror/gentoo/ "

AUTOCLEAN="yes"

ALSA_CARDS="intel8x0"

FEATURES="ccache"

CCACHE_DIR="/var/tmp/ccache"

CCACHE_SIZE="1G"
```

----------

## .:chrome:.

uhm... dovresti basarti solo su quello che ti dice top.

prima di tutto il kernel deve riconoscere due processori (cat /proc/cpuinfo), poi in top usa la visualizzazione a più processori (premi 1) e vedi cosa ti dice

----------

## Gr3yFox

Eccolo qui, sono presenti entrambi i core.

```
processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 43

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

...

processor       : 1

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 43

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

...

```

Anche top mostra entrambi i processori. Forse però era solo un caso che la compilazione di X non prendesse entrambi i core, per test ho fatto "emerge gvim" ed ad un certo punto ha raggiunto 100%.

Spiacente di aver dato fastidio per niente. Comunque almeno ho imparato quel comando di top che non conoscevo e quel file con informazioni sulle CPU  :Smile: 

Grazie mille per l'attenzione.

----------

## tizio

scusate l'intrusione...

anche io ho due cpu... che vengono riconosciute dal sistema.

lanciando emerge ho lo stesso problema (che forse non è un problema) di Gr3yFox...

praticamente tenendo sotto controllo l'utilizzo dei processori con top mi accorgo che le cpu vengono utilizzate contemporaneamente ma intorno al 20-30% l'una... per un utilizzo complessivo che si aggira intorno al 50%...

in questo modo però viene sfruttata completamente la "potenza" solo se ho più processi che lavorano in parallelo... (cosa abbastanza rara)

Il comportamento "giusto" non dovrebbe essere quello di alternare l'utilizzo delle due cpu? sfruttandole però al massimo?

grazie a tutti

ps: nel kernel sono già attivati il Symmetric multi-processing support e l'hyperthreading scheduler support

----------

## Gr3yFox

Non lo so tizio, magari fai qualche test aumentando le compilazioni simultanee, con un "-j4" al posto di "-j3" per esempio.

----------

## .:chrome:.

puntualizziamo... hai due CPU o una CPU HyperThreading?

sono cose ben diverse e utilizzare le routines SMP con una CPU HyperThreading (o viceversa) non è cosa buona

questo tanto per cominciare.

quello che poi segnali è un'ossrevazione fatta a spanne. come dicevo prima, l'unica cosa di cui ci si deve fidare (in quanto unica osservazione autoritaria) è quanto riportato da top. fai caso che lui mostra lo stato della CPU esattamente come viene letto dai sistemi UNIX, distinguendo il carico tra user, system e nice.

il carico globale è fatto dall'unione di questi tre che per forza di cose difficilmente raggiungeranno il 100%

se anche foss eil caso in cui il carico globale non supera mai il 30% (dubito fortemente che sia questo il caso) allora ci sarebbe effettivamente qualcosa di anomalo, la causa potrebbe essere un nice level troppo elevato, oppure un collo di bottiglia nel sistema

----------

## tizio

Una cpu hyperthreading...

Dici che devo lasciare l'hyperthreading scheduler support e levare il Symmetric multiprocess support (è questo che intendi per SMP routines)?

Comunque non ho detto che non supera mai il 30%... ma che lanciando un solo emerge si aggira intorno a quel valore...

e cmq i valori che ti ho riportato sono quelli che mi indica top.

grazie mille!

----------

## .:chrome:.

 *tizio wrote:*   

> Dici che devo lasciare l'hyperthreading scheduler support e levare il Symmetric multiprocess support (è questo che intendi per SMP routines)?

 

precisamente

 *tizio wrote:*   

> Comunque non ho detto che non supera mai il 30%... ma che lanciando un solo emerge si aggira intorno a quel valore...

 

allora si vede che è sufficiente. di cosa ti lamenti?  :Wink: 

----------

## tizio

scusa se insisto e scusa l'ignoranza...

ho tolto SMP dal kernel e le prestazioni sembrano invariate... 

ma all'avvio non mi vede più i due pinguini ma uno solo (sigh)

e anche top non mi rileva più le prestazioni di cpu1 ma solo cpu0...

forse che non è un hyperthreading ma son due cpu??? il portatile è un asus A4 e leggendo in giro mi sembrava d'aver capito fosse hyperthreading....

forse è giusto così? che non ci siano due pinguini e che mi veda una cpu sola?

ennesimo grazie!

----------

## tizio

oltretutto nella configurazione del kernel non è possibile lasciare l'hyperthreading scheduler support se tolgo il symmetric multiprocess support...

mi sa che va lasciato anche quello per fare in modo che me le veda come due cpu... anche se è una sola ma hyperthreading...

----------

## .:chrome:.

 *tizio wrote:*   

> oltretutto nella configurazione del kernel non è possibile lasciare l'hyperthreading scheduler support se tolgo il symmetric multiprocess support...
> 
> mi sa che va lasciato anche quello per fare in modo che me le veda come due cpu... anche se è una sola ma hyperthreading...

 

oddio... prima ho scritto una cazzata. non me ne ero reso conto

ti prego di scusarmi, ma mi ero fissato che le routines HyperThreading fossero indipendenti salla cofnigurazione SMP, ma non era così

----------

## Ic3M4n

volevo portare un'altra puntualizzazione di carattere generale: ci sono alcuni pacchetti che sono noti per avere dei problemi tipo instabilità o addirittura errori in compilazione se compilati con processi paralleli. il caso di xorg fornito prima ne è un'esempio principe, difatti in caso di pacchetti particolari l'ebuild filtra il valore -jN e lo porta di default a 1 quindi è logico in caso di sistemi multiprocessore, ht o semplicemente per tutti coloro che utilizzano abitualmente distcc vedere dei valori anomali o delle mancate migrazioni dei processi sulle altre macchine.

----------

## xdarma

Mi sembra di ricordare che nel ramo "stable" di gentoo, autoconf/automake/ecc. non supportano l'smp, quindi la compilazione "parte" su un solo processore. Una volta completato il configure, emerge inizia ad usare tutti i processori, salvo filtri specifici come riportato da Ic3M4n.

Nel ramo "unstable" dovrebbe essere presente una patch per rendere possibile l'uso di più processori anche nella fase di configure.

O almeno così mi sembrava di aver capito  ;-)

----------

## tizio

mi chiedevo se fosse possibile scegliere come distribuire il carico sulle varie cpu...

se distribuire il carico come fa ora oppure scegliere di alternare l'utilizzo delle cpu...

non so se mi son spiegato... 

magari per far confronti sui tempi di compilazione e temperatura del processore...

----------

## Kernel78

 *tizio wrote:*   

> mi chiedevo se fosse possibile scegliere come distribuire il carico sulle varie cpu...
> 
> se distribuire il carico come fa ora oppure scegliere di alternare l'utilizzo delle cpu...
> 
> non so se mi son spiegato... 
> ...

 

Sai che non riesco a capire il motivo ? sarebbe come dire: "con due gambe riesco a fare i 100 m in 10 secondi, vediamo quanto tempo ci metto usando una gamba sola"   :Laughing: 

----------

## .:chrome:.

 *tizio wrote:*   

> mi chiedevo se fosse possibile scegliere come distribuire il carico sulle varie cpu...

 

no. non è possibile.

è solo compito dello scheduler decidere come distribuire i processi (a volte non dipende nemmeno da lui, vedi i processori HT). puoi al massimo decidere la polita di scheduling, influenzando in modo marginale, ma sensibile, il modo in cui lo scheduler lavora

----------

## Gr3yFox

Dunque è per problemi di instabilità che emerge ha deciso di distribuire la compilazione di X su un solo core... spiegazioni veramente molto chiare, grazie ancora  :Smile: 

----------

## Trifaux666

adesso che hai risolto il problema, aggiungi il tag [risolto] al titolo (puoi farlo modificando il titolo del primo messaggio)

----------

## Gr3yFox

Ok, ora lo aggiungo.

edit: ho dovuto modificare leggermente il titolo della discussione per farlo stare nei limiti imposti.

----------

## xdarma

Se vuoi fare delle prove comparative mono/biprocessore ti conviene provare disabilitando un processore e non pilotando la gestione dei processi.

La tua domanda mi ricorda qualcosa.... prova a guardare qui: Dividere carico sulle CPU

:-)

----------

## silvius

Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ?

Saluto

----------

## randomaze

 *silvius wrote:*   

> Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ?

 

Dipende in quale momento lo fai. Se compili piccoli pacchetti (e molti lo sono) probabilmente il tempo maggiore lo impiega per cancellare e installare rispetto ai brevi istanti per compilare tre o quattro file...

----------

## silvius

 *randomaze wrote:*   

>  *silvius wrote:*   Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ? 
> 
> Dipende in quale momento lo fai. Se compili piccoli pacchetti (e molti lo sono) probabilmente il tempo maggiore lo impiega per cancellare e installare rispetto ai brevi istanti per compilare tre o quattro file...

 

Ok per i pacchetti piccoli, ma per i più grossi durante la vera compilazione come si dovrebbe comportare utilizzo delle cpu ?

Cioè deve essere quasi costante sui 70%-90% o è giusto tra 20%-90%.

----------

## randomaze

 *silvius wrote:*   

> Ok per i pacchetti piccoli, ma per i più grossi durante la vera compilazione come si dovrebbe comportare utilizzo delle cpu ?
> 
> Cioè deve essere quasi costante sui 70%-90% o è giusto tra 20%-90%.

 

Beh se il delay fosse a 1 e tu stessi compilando un file di dimensioni corpose dovrebbe andare oltre il 90... 

Comunque più che top per queste prove ti conviene usare gkrellm o altro monitor che non fa la separazione system/idle/...

----------

## silvius

 *randomaze wrote:*   

>  *silvius wrote:*   Ok per i pacchetti piccoli, ma per i più grossi durante la vera compilazione come si dovrebbe comportare utilizzo delle cpu ?
> 
> Cioè deve essere quasi costante sui 70%-90% o è giusto tra 20%-90%. 
> 
> Beh se il delay fosse a 1 e tu stessi compilando un file di dimensioni corpose dovrebbe andare oltre il 90... 
> ...

 

Adesso ho fatto caso che da quando ho emerso kde in top ( lanciato da terminale ) mi trovo molti processi che iniziano con K...., è normale ?

Saranno questi processi che rallentano il sistema ? ( utilizzo cpu non ne hanno )

Posso killarli , visto che quando uso il terminale non mi interessa kde ?

Saluto

----------

## .:deadhead:.

forse è meglio uscire da kde anzichè killarli brutalmente...  :Rolling Eyes: 

----------

## silvius

 *.:deadhead:. wrote:*   

> forse è meglio uscire da kde anzichè killarli brutalmente... 

 

Infatti quei processi li ho senza caricare kde, li ho appena mi loggo nel terminale.

Saluto

----------

## Dece

 *silvius wrote:*   

> Infatti quei processi li ho senza caricare kde, li ho appena mi loggo nel terminale.

 

Allora ti dovrebbe nascere il sospetto che non siano processi relativi a kde, ma al kernel... e che quindi non conviene killarli   :Rolling Eyes: 

----------

## silvius

 *Dece wrote:*   

>  *silvius wrote:*   Infatti quei processi li ho senza caricare kde, li ho appena mi loggo nel terminale. 
> 
> Allora ti dovrebbe nascere il sospetto che non siano processi relativi a kde, ma al kernel... e che quindi non conviene killarli  

 

mi sa che hai ragione ti posto un ps aux:

```
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

root         1  0.0  0.0   1476   520 ?        Ss   00:55   0:01 init [3]

root         2  0.0  0.0      0     0 ?        S    00:55   0:00 [migration/0]

root         3  0.0  0.0      0     0 ?        SN   00:55   0:00 [ksoftirqd/0]

root         4  0.0  0.0      0     0 ?        S    00:55   0:00 [migration/1]

root         5  0.0  0.0      0     0 ?        SN   00:55   0:00 [ksoftirqd/1]

root         6  0.0  0.0      0     0 ?        S<   00:55   0:03 [events/0]

root         7  0.0  0.0      0     0 ?        S<   00:55   0:00 [events/1]

root         8  0.0  0.0      0     0 ?        S<   00:55   0:00 [khelper]

root         9  0.0  0.0      0     0 ?        S<   00:55   0:00 [kthread]

root        12  0.0  0.0      0     0 ?        S<   00:55   0:00 [kblockd/0]

root        13  0.0  0.0      0     0 ?        S<   00:55   0:00 [kblockd/1]

root        14  0.0  0.0      0     0 ?        S<   00:55   0:00 [kacpid]

root       142  0.0  0.0      0     0 ?        S<   00:55   0:00 [kseriod]

root       145  0.0  0.0      0     0 ?        S<   00:55   0:00 [khubd]

root       228  0.0  0.0      0     0 ?        S    00:55   0:00 [kswapd0]

root       229  0.0  0.0      0     0 ?        S<   00:55   0:00 [aio/0]

root       230  0.0  0.0      0     0 ?        S<   00:55   0:00 [aio/1]

root       231  0.0  0.0      0     0 ?        S<   00:55   0:00 [cifsoplockd]

root       232  0.0  0.0      0     0 ?        S<   00:55   0:00 [cifsdnotifyd]

root       832  0.0  0.0      0     0 ?        S<   00:55   0:07 [vesafb]

root       851  0.0  0.0      0     0 ?        S<   00:55   0:00 [kpsmoused]

root       873  0.0  0.0      0     0 ?        S<   00:55   0:00 [ata/0]

root       874  0.0  0.0      0     0 ?        S<   00:55   0:00 [ata/1]

root       876  0.0  0.0      0     0 ?        S<   00:55   0:00 [scsi_eh_0]

root       880  0.0  0.0      0     0 ?        S<   00:55   0:00 [scsi_eh_1]

root       943  0.0  0.0      0     0 ?        S    00:55   0:00 [kirqd]

root       945  0.0  0.0      0     0 ?        S<   00:55   0:01 [kjournald]

root      1145  0.0  0.0   1712   536 ?        S<s  00:55   0:00 /sbin/udevd --daemon

root      7045  0.0  0.1   3380   920 ?        Ss   00:55   0:00 /usr/sbin/sshd

root      7061  0.0  0.1   2176  1008 ?        Ss   00:55   0:00 login -- root

root      7062  0.0  0.1   2176  1008 ?        Ss   00:55   0:00 login -- root

root      7063  0.0  0.1   2172  1016 ?        Ss   00:55   0:00 login -- utente

root      7067  0.0  0.0   1616   696 tty4     Ss+  00:55   0:00 /sbin/agetty 38400 tty

root      7068  0.0  0.0   1620   704 tty5     Ss+  00:55   0:00 /sbin/agetty 38400 tty

root      7070  0.0  0.0   1616   704 tty6     Ss+  00:55   0:00 /sbin/agetty 38400 tty

root      7101  0.0  0.1   2324  1368 tty1     Ss+  00:55   0:01 -bash

root      7478  0.0  0.1   2332  1408 tty2     Ss+  01:12   0:02 -bash

utente   19663  0.0  0.1   2588  1376 tty3     Ss+  09:35   0:00 -bash

root     19935  0.0  0.2   6376  2028 ?        Ss   10:13   0:01 sshd: root@pts/0

root     19938  0.0  0.1   2324  1388 pts/0    Ss   10:13   0:00 -bash

root      2752  0.0  0.0      0     0 ?        S    10:33   0:00 [pdflush]

root      2753  0.0  0.0      0     0 ?        S    10:33   0:00 [pdflush]

root     11339  0.0  0.0   2464   868 pts/0    R+   11:39   0:00 ps aux
```

Sono del kernel ?

Saluto

----------

## randomaze

 *silvius wrote:*   

> Adesso ho fatto caso che da quando ho emerso kde in top ( lanciato da terminale ) mi trovo molti processi che iniziano con K...., è normale ?
> 
> Saranno questi processi che rallentano il sistema ? ( utilizzo cpu non ne hanno )
> 
> Posso killarli , visto che quando uso il terminale non mi interessa kde ?

 

Killare i processi che iniziano con k? Ti ricordo che la lettera 'k' non é l'iniziale solo di KDE ma anche di kernel (ad esempio ksoftirqd, kjournald, kswap...). Poi fai un pò tu.

Cosa vorresti intendere con "rallentano il sistema"? Se il tuo problema é che non vedi il 100% di CPU al limite sarebbe il contrario: se non viaggia al 100% allora non é rallentato (ma il discorso é decisamente molto più lungo e complesso di una semplice frase).

----------

## .:deadhead:.

 :Shocked:  beh può esser un'esperienza, come giocare a psDoom o a Brutal File Manager

----------

## 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 wrote:*   

> Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ?

 

si ma non vorrei dire... ma ricordo non molto tempo fa uno che ha fatto la stessa identica domanda.

invece che fare domande a raffica perché non cercare nel forum o nella documentazione?

la gente si stufa anche di leggere di forum, in questo modo

----------

## silvius

 *k.gothmog wrote:*   

>  *silvius wrote:*   Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ? 
> 
> si ma non vorrei dire... ma ricordo non molto tempo fa uno che ha fatto la stessa identica domanda.
> 
> invece che fare domande a raffica perché non cercare nel forum o nella documentazione?
> ...

 

Scusa, hai ragione adesso l' ho trovato ( https://forums.gentoo.org/viewtopic-t-461566-highlight-compilazione+cpu.html ).

Potevo trovarlo anche prima, si vede che avevo inserito chiavi di ricerca non corrette.

Una domanda, nel post vecchio si parla di un problema di pacchetti che possono dare errori se compilati in multithread, ma per far lavorare le due cpu si potrebbe fare due emerge ( lo sò è pericoloso ). Magari una volta fatto un emerge -pv pacchetto si puo fare uno script che fà due emerge con pacchetti non comuni. No?

Quindi il MAKEOPTS serve solo per la concorrenza dei threads all' interno dello stesso processore ?

Saluto

----------

## randomaze

 *silvius wrote:*   

> Scusa, hai ragione adesso l' ho trovato ( https://forums.gentoo.org/viewtopic-t-461566-highlight-compilazione+cpu.html ).

 

Ho fatto il merge dei due, grazie per la segnalazione  :Wink: 

----------

## .:chrome:.

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

 *Quote:*   

> # MAKEOPTS provides extra options that may be passed to 'make' when a
> 
> #     program is compiled. Presently the only use is for specifying
> 
> #     the number of parallel makes (-j) to perform. The suggested number
> ...

 

se non fosse chiaro cosa vuol dire basta osservare l'output di PS, dove si vede chiaramente che vengono invocate più (due nel mio caso) istanze di make, che se ne vanno in parallelo.

----------

## !equilibrium

 *silvius wrote:*   

> Se durante una compilazione lancio top, la cpu raramente raggiunge il 99,9% e normalmente viaggia tra 20%-90% è normale ?

 

se si ha un sistema con supporto alle NPTL e si vuole che il comando 'top' riporti tutti i threads (di default non lo fa) bisogna premere H (shift + h). Si ottengono informazioni più precise e una visione più completa dei processi che girano.

----------

## 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 wrote:*   

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

 

bella domanda  :Laughing: 

quoto in pieno il tuo post  :Wink: 

----------

## 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

 *kueitao wrote:*   

> In questo thread si sono trattati diversi ...........................
> 
> [CUT]
> 
> .................................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.
> ...

 

( NON SO' SE HO BEN CAPITO, CHIEDO CONFERMA )

Quindi avere n° thread ( multithreading )elevati non pagha visto che vanno in concorrenza fra loro e di conseguenza rischi di avere molto tempo di switch.

Invece se ho più processi ( multi-processor ) non si dovrebbe avere la possibilità di scalare meglio rispeto a far scalare i thread ?

Per il problema degli i/o, è meglio scalare su più macchine anzichè scalare su una multiprocessore, giusto ?

Nel caso uno volesse scrivere del codice di qualità, per vedere se effettivamente gli conviene fare un fork() o aprire più thread per lo stesso processo,  non ha altro modo che provare, giusto ? 

Lato scheduler, cambia qualcosa da gestire un thread o un processo ?

Saluto

----------

## randomaze

 *silvius wrote:*   

> ( NON SO' SE HO BEN CAPITO, CHIEDO CONFERMA )
> 
> ...
> 
> 

 

silvius, le rispste complete alle tue domande dovrebbero occupare circa un paio di corsi universitari... e forse anche un complementare.

L'unica cosa che mi sento di dirti (a parte chiarirti le idee con almeno un buon libro sull'argomento, decisamente piú chiaro ed esaustivo di quello che puó fare un thread su un forum) é: dipende.

Ci sono situazioni in cui ha senso duplicare il processo con una fork() e altre in cui conviene avviare un thread, altre ancora in cui conviene ragionare in termini di calcolo parallelo su piú macchine. Naturalmente ci sono situazioni in cui un normale programma lineare basta e avanza.

Non ci sono molte situazioni in cui ci sia bisogno di "provare" se non quelle in cui l'analisi del problema é stata fatta da una persona con due braccia strappate all'agricoltura (intendiamoci, bracciante o zappaterra non certo contadino).

Oltretutto anche mettendosi a fare prove potresti scoprire che su Linux 2.4 hai dei risultati, su Linux 2.6 i risultati sono diversi, su OpenSolaris altri ancora e su *BSD risoltati ancora diversi.

----------

## silvius

 *randomaze wrote:*   

>  *silvius wrote:*   ( NON SO' SE HO BEN CAPITO, CHIEDO CONFERMA )
> 
> ...
> 
>  
> ...

 

Viste le mie curiosità, mi sa che ho sbagliato corso. Nel corso di informatica non si analizzavano queste cose.

Comunque queste cose ( multithreading e multiproce3ssor ) non vengono generalmente affrontate da chi sviluppa applicativi, quindi difficilmente si avrà codice che scali bene, No ? 

Saluto

----------

## 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.

 *silvius wrote:*   

> ( NON SO' SE HO BEN CAPITO, CHIEDO CONFERMA )
> 
> Quindi avere n° thread ( multithreading )elevati non pagha visto che vanno in concorrenza fra loro e di conseguenza rischi di avere molto tempo di switch.

 

NO.   :Smile: 

(1) Non esistono solo macchine mono-processore e le macchine con due o più processori possono far eseguire in parallelo i compiti dei diversi thread risultando in parecchi casi molto più performanti della precedente anche se devono sincronizzare i dati tra nodi. Ovviamente il discorso può valere anche per HT e Dual-Core, ma i costi/benefici vanno analizzati di volta in volta in fase di progettazione del software e tenendo conto, quando è possibile, dell'architettura delle macchine che poi eseguiranno il codice.

(2) Anche in macchina mono-CPU più thread in esecuzione possono e sicuramente spesso fanno meglio (almeno se non sono troppi). Il motivo risiede nel fatto che quando un thread è in attesa di un qualche evento (I/O e altre cose) può essere messo a riposo dal SO e nel contempo la stessa CPU può avanzare il secondo thread. 

Questo è ad esempio il motivo per il quale si consiglia il parametro MAKEOPTS="numero di CPU+1". Durante le compilazioni, il compilatore ha continua necessità di effettuare I/O o di attendere comunque altri eventi. Mentre un processo attende l'altro prosegue sulla stessa CPU. Nota che qui si tratta di processi differenti, due sessioni GCC, ma la differenza con i thread è molto sottile e il discorso vale per entrambi gli strumenti.

 *silvius wrote:*   

> 
> 
> Invece se ho più processi ( multi-processor ) non si dovrebbe avere la possibilità di scalare meglio rispeto a far scalare i thread ?
> 
> 

 

NO.   :Smile:   :Smile: 

Dipende sempre dal CONTESTO ed infatti se fosse come temi il concetto di thread non esisterebbe. Non ti pare? Esistono parecchie considerazioni che l'ingegnere del software deve valutare per scegliere al meglio la prima o la seconda soluzione o addirittura un misto delle due tecnologie.

In breve ti faccio l'esempio di uno tra gli aspetti da considerarsi più importanti. Prima di tutto si deve verificare a progetto se è meglio un solo thread di esecuzione o se, per vari motivi, si preferisce un esecuzione parallela ad 'n' threads o processi. Nel caso si siano scelti più "percorsi concorrenti di esecuzione" si affronta il successivo problema. 

In termini del tutto GENERALI e APPROSSIMATIVI scelgo il MULTI-THREADING quando voglio l'esecuzione parallela di codice che manipola COMPLESSE STRUTTURE DATI COMUNI, mentre scelgo il MULTI-PROCESSING quando voglio l'esecuzione parallela di codice che NON deve manipolare  COMPLESSE STRUTTURE DATI COMUNI.

Non mi è facile spiegare qui tutti i ragionamenti che stanno dietro a tali "propensioni" più che vere è proprie "regole". Sinteticamente si sappia che più thread (iniziati con pthread_create()) hanno "naturalmente" accesso a tutte le strutture dati globali del processo ed il maggiore problema sta proprio nel sincronizzare ed escludere (semafori e mutex) di volta in volta certe parti di codice dal poter accedere a tali dati mentre questi sono manipolati da un altro thread al quale è stato consentito l'accesso. Invece tra processi diversi (fork() ed exec()) non esiste "naturalmente" la condivisione dei dati e quindi il programmatore deve mettere in piedi dei meccanismi di IPC (Inter Process Communication) per scambiare dati tra questi. In conclusione: con i thread c'è il problema di ordinare e mutuamente escludere l'accesso a dati globali di processo, mentre con il multi-processing non abbiamo il precedente problema perché gli eventuali dati sui quali si vuole operare da più processi devono essere appositamente trasferiti. Il risultato è che spesso la programmazione con i thread è più compleassa e gli errori sono notevolmente più probabili e spesso difficili da identificare.  

 *silvius wrote:*   

> Per il problema degli i/o, è meglio scalare su più macchine anzichè scalare su una multiprocessore, giusto ?

 

Ad averle! Ma neanche questo è del tutto vero sempre.   :Smile:   :Smile:   :Smile: 

Ricorda che il trasferimento dei dati è molto più veloce tra più nodi processore della stessa macchina SMP che ad esempio attraverso una rete con il protocollo TCP/IP. Quindi anche qui dipende da quale massa di dati è necessario che i processi debbano scambiarsi tra loro e da un'altra serie di considerazioni. Di solito le reti estese di computer sono usate per processi concorrenti che devono eseguire parecchi calcoli e scambiarsi magari solo i dati iniziali e alla fine una ridotta quantità di risultati risultati. Vedi ad esempio il progetto SETI@HOME. Ovviamente anche qui il discorso è molto compleaaso ed esistono parecchie eccezioni che invalidano il precedente ragionamento.

 *silvius wrote:*   

> Nel caso uno volesse scrivere del codice di qualità, per vedere se effettivamente gli conviene fare un fork() o aprire più thread per lo stesso processo,  non ha altro modo che provare, giusto ?

 

NO, ancora!    :Smile:   :Smile:   :Smile:   :Smile: 

Per fortuna non è lasciato alle prove empiriche. Ho mostrato esempi dove ragionamenti a priori, insieme a molti altri non citati ed altrettanto importanti, consentono di operare una scelta in anticipo. Del resto sarebbe assurdo scrivere magari migliaia di righe di codice da doversi successivamente modificare di brutto a seguito di valutazioni a posteriori.

Il bravo ingegnere del software (developer?), attraverso lo studio e l'esperienza nel progettare, è in grado di valutare la bontà di una soluzione a priori e/o in corso di test di porzioni di codice (moduli, funzioni, ecc.). Per la progettazione e realizzazione di "codice di qualità" si devono conoscere le caratteristiche della macchina/e su cui eseguirà, il sistema operativo, un linguaggio che fornisce i meccanismi per manipolare anche i dettagli più low-level (come C/C++/Ada e altri) ed il suo compilatore che emetta codice di qualità e con molte estensioni rispetto al linguaggio standard (il GCC è fenomenale nell'offrire quelle estensioni che consentono al programmatore di influire al massimo sulla qualità del codice emesso), un po' di Assembly in-line per ottimizzare passaggi critici e poi chissà quante altre 'cosine' che al momento non mi vengono in mente.

In pratica però succede che molti sedicenti software engineers tali non sono nei fatti e non hanno nessuna o poche idee degli argomenti che ho citato. Per cui utilizzarenno il multi-processing dove il multi-threading sarebbe più adatto e viceversa. Accade anche che con alcuni linguaggi troppo high-level (intendo sempre rispetto all'hardware) non si possa proprio operare certe scelte. Non per niente la quasi totalità delle applicazioni che girano su un GNU/Linux sono realizzate in C/C++ ESTESI ed arricchiti di codice Assembly dove necessario. Il GNU/C con il quale è realizzato il Linux Kernel è proprio una estensione del C standard che consente un elevatissimo controllo sul codice emesso per sfruttare al meglio le differenti macchine su cui è implementato (dai PC portatili ai mainframe).  Ma questo è un altro discorso...

 *silvius wrote:*   

> Lato scheduler, cambia qualcosa da gestire un thread o un processo ?

 

Esclusivamente "lato scheduler" direi che non cambia quasi niente. Visto che studi Informatica, perché non ti leggi il codice sorgente di Linux? Li hai tutte le risposte, anche in merito a quali sono le "best practises" nell'implementazione di uno generico kernel. Comunque non è facile, magari dopo aver dato le materie che ti citavo all'inizio riuscirai a seguirlo meglio. 

Saluti.

fabio de francesco

PS.: Come ho scritto in un post più sopra, sembra che queste o similari domande vengono spesso fuori ciclicamente. Si può costruire, con la collaborazione di altri che conoscono questi argomenti una specie di FAQ a cui far puntare chi vuole risposte? Esiste qualcosa del genere magari su altri temi?

----------

## 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

----------

