# sarà vero?

## cloc3

diavolo!

così facile?

cosa ne pensate? io, fino ad ora, le impostazioni di cgroup del kernel non le settavo neppure.

ps: pietà, bandite i commenti sul modo in cui punto-informatico chiude i propri articoli

----------

## xdarma

 *cloc3 wrote:*   

> diavolo!
> 
> così facile?
> 
> cosa ne pensate? io, fino ad ora, le impostazioni di cgroup del kernel non le settavo neppure.
> ...

 

Ne parlano anche qui: [RFC/RFT PATCH v3] sched: automated per tty task groups

e sembra sia vero per alcuni casi.

E sinceramente stavo proprio pensando di provare uno di 'sti kernel unstable+patch  :-)

Per quanto riguarda punto-informatico/microsoft russia... il fatto stesso che ci siano miglioramenti così importanti nel kernel significa che c'è ancora spazio per i miglioramenti, altro che "fine del ciclo vitale"  ;-)

----------

## cloc3

 *xdarma wrote:*   

> 
> 
> e sembra sia vero per alcuni casi.
> 
> 

 

alcuni quali?

val la pena provarla su un desktop normale, dove lavora un utente alla volta, o è necessario un sistema dove lavorano contemporaneamente più utenti?

perché associare un processo ad un determinato gruppo determina dei vantaggi nelle prestazioni?

come è possibile fare una misurazione dei guadagni?

ho settato il mio aspireOne in un attimo, con il metodo in linea di comando. non me la sento, però, di fare affermazioni speriticate sui guadagni, se non trovo un metodo di misura convincente.

 *xdarma wrote:*   

> altro che "fine del ciclo vitale"

 

sinceramente non mi importa cosa pensi il capoccia sovietico. mi preoccupa che un giornalista infili degli OT così a sporposito solo per il gusto di accostare gratuitamente una nota negativa che distolga dal contenuto della notizia.

----------

## ciro64

[ot]

Mah... rispetto a "Finestre" a me sembra che ci sia già un abisso prestazionale tanto che per me svista è usato solo come fotocopiatrice (questo finchè non avrò barattato il mio scanner).

anzi mi sa che compererò un pc più lento; se diviene ancora più veloce poi mi mette davvero paura.

Insomma già così posso 

compilare (con -j5 su q9450)

navigare

vedere film con xbmc

usare skype con invio immagine desktop

pilotare pc di mio amico con ssh

avere desktop effects attivi

in più boinc a pieno regime sempre attivo

tutto contemporaneamente

Qualche scatto ce l'ho solo quando boinc usa intensamente cuda. ed anche in questo caso è sempre immensamente più performante di "Finestre" ove mi viene il latte alle ginocchia nell'attendere che exploer (che spesso smette di funzionare quindi devo attenderlo) torni disponibile.

Insomma: ho anche fatto vedere come gira Gentoo su un athmon 64 x2 @ 2,0 GHz ad un mio amico che è anche un utente mac e da un po' non uas OS Linux.

Parole sue.. è rimasto "allibito" dalla velocità nel multitasking (kde + kwin effects attivi)

Quel tovarish li...... è solo un invidioso guastafeste  :Laughing: 

[/ot]

Sper di non aver rotto troppo le scatole con questo post. mi concedete questo piccolo sfogo ?

Ciao  :Smile: 

----------

## mack1

Ciao sto provando la versione "bash" su un p4 con scarse risorse e mi pare funzioni (test a occhio  :Shocked:  );agisce solo sui processi lanciati da una shell che vengono gestiti con cgroup....in pratica il p4 usa costantemente buona parte della cpu, senza la gestione "cgroup" firefox parte in una 10 di secondi, con cgroup in un paio.

Test approfonditi non ne ho compiuti, però non sembra una bufala  :Very Happy:  :

http://lkml.org/lkml/2010/10/19/212

http://lkml.org/lkml/2010/10/19/226

http://lkml.org/lkml/2010/10/19/341

Altro esempio aggiornando il sistema con emerge (uso --jobs --load-average in make.conf), il DE risulta più reattivo, però emerge, tende ad impiegare più tempo per la compilazione...c'è una gestione del "cpu time" dei jobs di emerge che non penalizza il resto dei processi, introducendo però overhead a livello di scheduler (gestione tramite cgroup), quindi un throughput complessivo inferiore, ma una maggiore reattività del DE e dei suoi task (io l'ho capita in questi termini, se mi sbaglio chiedo scusa e mi correggerete  :Wink:  ) 

Problemi fino ad ora non ne ho avuti; la versione 4 della patch per il kernel ha introdotto una nuova gestione, non più per tty ma in base alla sessione (fornendo una gestione più granulare):

Post: post 6493016

Ciao

----------

## cloc3

 *ciro64 wrote:*   

> 
> 
> Quel tovarish li...... è solo un invidioso guastafeste 
> 
> 

 

poverino, lui che centra?

è vecchio, quasi come me.

sarà una dozzina d'anni che non scrive una riga di codice.

non ci aveva neanche pensato a questo rattoppo nei cgroup.

è tutta colpa di quegli studipi hacker che sbucano da tutte le parti come le cavallette.

e gli piazzano miccette nel sedere a sua insaputa, con le patch microstampante sulla carta di protezione.

se non li arrestano tutti, dove andremo a finire?

 :Evil or Very Mad: 

----------

## djinnZ

Per come è diventata M$ credo che non abbia mai scritto in vita sua una riga di codice e che la sua formazione sia di ordine legale/economico o sarà la solita crapa del marketing.

I tempi in cui un programmatore poteva diventare capo sono passati da troppi anni.

Che doveva dire di fronte al rischio di perdere il posto? Mica è come il suo collega italiano che ha lo stato dalla sua parte...

Il problema lo hai centrato prima ma per PI è normale tentare di fomentare il trolleggio nei commenti o è cambiato qualcosa dall'ultima volta che lo ho letto.

----------

## xdarma

 *cloc3 wrote:*   

>  *xdarma wrote:*   
> 
> e sembra sia vero per alcuni casi.
> 
>  
> ...

 

Per quello che c'ho capito io, l'utente DontPanicqui riporta i risultati dei suoi test e, grossomodo:

sei vuoi bassa latenza ricordati di impostare autogroup=1 ma preparati ad aspettare un pò più a lungo.

Ovviamente se ne fai un uso desktop credo sia proprio quello che cerchi.

 *cloc3 wrote:*   

> val la pena provarla su un desktop normale, dove lavora un utente alla volta, o è necessario un sistema dove lavorano contemporaneamente più utenti?
> 
> perché associare un processo ad un determinato gruppo determina dei vantaggi nelle prestazioni?
> 
> come è possibile fare una misurazione dei guadagni?

 

Non ne ho la minima idea, sorry.

 *cloc3 wrote:*   

> sinceramente non mi importa cosa pensi il capoccia sovietico. mi preoccupa che un giornalista infili degli OT così a sporposito solo per il gusto di accostare gratuitamente una nota negativa che distolga dal contenuto della notizia.

 

A essere buono direi che "anche lui tiene famiglia" a essere cattivo direi che "anche lui è a libro paga"  :-p

 *mack1 wrote:*   

> senza la gestione "cgroup" firefox parte in una 10 di secondi, con cgroup in un paio.

 

8-...]                 (esiste un emoticon testuale per la caduta della mascella?)

Molto interessante, grazie.

Per curiosità: che kernel hai usato?

----------

## mack1

 *Quote:*   

> 
> 
> Per curiosità: che kernel hai usato?
> 
> 

 

Ciao xdarma: 

root@Shell:23:38:0:~>uname -a

Linux Shell 2.6.35-hardened-r7 #3 SMP PREEMPT Sat Nov 20 11:31:05 CET 2010 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

Ciao

----------

## xdarma

Piccolo aggiornamento:

per i test sembra utile wakeup-latency anche se non ho capito come sfruttarlo concatenandolo con un benchmark tipo sysbench.

La patch "magica" è già stata inclusa nel kernel 2.6.36-r2 dei gentoo-sources ma è masked e non va d'accordo con gli nvidia-drivers che uso attualmente, quindi devo fare l'upgrade dei driver nvidia alla versione 260.19.21 ed estenderla al kernel .34-r12.

Solo per avere un minimo di attendibilità.

Spero di avere un pò di tempo in settimana, sono curioso di vedere se si "sveglia" 'sto baraccone di linuxbox  ;-)

----------

## Deus Ex

@xdarma

Tienici aggiornati!  :Smile: 

----------

## xdarma

Ho sistemato i kernel e i driver nvidia e ho pensato di usare tre kernel gentoo:

34-r12.default (il kernel stabile in amd64 e che uso solitamente);

34-r12.cgroups (lo stesso kernel ma con le opzioni relative a cgroups abilitate);

36-r2.patched (il kernel gentoo con la patch "magica").

Il test che lancio da konsole (tre volte) e ne faccio la media è:

```
wakeup-latency-signal & sysbench --num-threads=3 --test=threads run && kill %1
```

La macchina è un dual-core con boinc attivo al 100% e anche un video con kmplayer tanto per tenerlo d'occhio ;-)

I numeri al momento sono questi:

34-r12.default

```
media - maximum latency = 947.4 µs

media - average latency = 61.0 µs

totale - missed timer events: 0
```

34-r12.cgroups

```
media - maximum latency = 1488.7 µs

media - average latency = 174.2 µs

totale - missed timer events: 0
```

36-r2.patched

```
media - maximum latency = 2156.3 µs

media - average latency = 53.1 µs

totale - missed timer events: 1
```

Numeri a parte, le sensazioni usando lo "spannometro" sono che il 34-r12.default è abbastanza lento a rispondere, il 34-r12.cgroups sembra più vivace e che il 36-r2.patched è il più reattivo.

Proprio il 36-r2.patched ha un "problemino": ogni tanto si blocca tutto, anche per due minuti (!), dopo si sblocca e riparte come niente fosse...

Ci saranno sicuramente delle opzioni nella compliazione che ho sbagliato (generalmente abilito tutto quello che ha a che fare con low-latency/preemtible) ma ho il "sospetto" che sia prematuro usarlo. D'altronde se è marcato come masked ci sarà qualche bug da eliminare ;-)

Volevo provare i tre kernel anche con la versione modificata di bash, ma intanto potete dirmi se il test è corretto o se, effettuato in questo modo, è praticamente inutile.

Ciao e grazie.

----------

## MajinJoko

mhh.. come mai io mi blocco subito:

 *Quote:*   

> # mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
> 
> mount: il mount point /sys/fs/cgroup/cpu non esiste

 

controllando, però:

 *Quote:*   

> # grep -i "cgroup" .config
> 
> CONFIG_CGROUPS=y
> 
> # CONFIG_CGROUP_DEBUG is not set
> ...

 

c'é qualcosa che mi manca?   :Question: 

----------

## xdarma

 *MajinJoko wrote:*   

> mhh.. come mai io mi blocco subito:
> 
>  *Quote:*   # mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
> 
> mount: il mount point /sys/fs/cgroup/cpu non esiste 

 

Prova con il metodo alternativo basato su /dev e non su /sys, sostanzialmente sempre da: Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away

 *MajinJoko wrote:*   

> 
> 
> controllando, però:
> 
>  *Quote:*   # grep -i "cgroup" .config
> ...

 

Sul thread "ufficiale" di gentoo altri utenti hanno notato la stessa cosa.

Anche io ho qualche perplessità, posto i risultati degli stessi test usati nel post sopra, con gli stessi kernel. La differenza è che ho abilitato le modifiche in .bashrc e local.start:

34-r12.default

```
media - maximum latency = 833.2 µs

media - average latency = 50.7 µs

totale - missed timer events: 0
```

34-r12.cgroups

```
media - maximum latency = 4065.6 µs

media - average latency = 193.1 µs

totale - missed timer events: 0
```

36-r2.patched

```
media - maximum latency = 3859.2 µs

media - average latency = 337.2 µs

totale - missed timer events: 0
```

Grossomodo i kernel con cgroups abilitati (cgroups e patched) sono peggiorati, quello che non ha i cgroups abilitati (default) è migliorato...

Purtroppo i risultati non mi sembrano coerenti tra loro e quindi ho il forte sospetto di aver fatto un buco nell'acqua...  :-D

----------

## MajinJoko

 *xdarma wrote:*   

> Prova con il metodo alternativo basato su /dev e non su /sys, sostanzialmente sempre da: Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away

 

Niente da fare, cgroups non è nemmeno in dev. Boh!

Grazie  :Wink: 

----------

## cloc3

 *MajinJoko wrote:*   

> 
> 
> Niente da fare, cgroups non è nemmeno in dev. Boh!
> 
> 

 

la cartella deve essere creata a mano.

c'è scritto anche nell'howto che lincato in cima al thread.

----------

## MajinJoko

nell'how to dice: *Quote:*   

> mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
> 
> mkdir -m 0777 /sys/fs/cgroup/cpu/user

 

da qui la mia confusione, visto che per come è scritto, /sys/fs/cgroup/cpu/ dovrebbe esistere. Infatti non usa mkdir -p.

Grazie per il chiarimento.

----------

## table

Sapete se questa patch è inclusa anche nel nuovo kernel stabile 2.6.36-r5 ?

----------

## xdarma

 *table wrote:*   

> Sapete se questa patch è inclusa anche nel nuovo kernel stabile 2.6.36-r5 ?

 

Mi sembra di no. Almeno in base al changelog dei gentoo-sources e al blog di M.Pagano.

Inoltre dal menù di configurazione del kernel 2.6.36-r5 manca l'opzione "autogroup".

Intanto che aspetti che diventi stabile, ricordati di abilitare Block IO controller [BLK_CGROUP]  ;-)

----------

