[semi-risolto] chiarimenti vari su cpufrequtils

[johnnystuff]

Tanti piccoli problemi forse ne fanno uno grande...... vediamo da dove partire: l'output di /proc/cpuinfo. Forse è normalissimo, ma una volta (tipo fino a un mese fa mi pare) non mostrava le informazioni separate per ogni core, ma vabbè. Il problema è che guardando quell'output mi sono accorto che le policy di cpufrequtils vengano assegnate solo al primo core, o addirittura solo al primo e all'ultimo o_O
Per la cronaca. ho un PhII X3 col 4° core sbloccato da bios e overclockato a 3.4 (sempre da bios perchè è un black edition). In pratica senza che vi incollo 10 pagine di roba succede così: se imposto il governor di default a "userspace" mi stan sempre tutti alla massima freq (3.4Ghz, e il procio scalda parecchio), se lo metto a powersave solo il primo core va a 800Mhz e gli altri restano a 3.4 idem con altri governor.
Inoltre ora è successa una cosa strana: ho provato a settare a mano le freq a 2.1 con un #cpufreq-set -f 2.1ghz ma le ha applicate solo al primo e all'ultimo core (gli altri sempre 3.4), dopodichè ora se cambio governor (per esempio performance per tornare con tutto al max) il primo va a 3.4 ma l'ultimo resta a 2.1, idem se butto giù con powersave, il primo ci va, 2° e 3° sempre a 3.4 e il 4° resta a 2.1 +_+

Eppure sembra che la voce che fa riferimento sia solo quella relativa al primo core, perchè buttandolo giù a 800 raffredda subito nonostante in teoria gli altri 3 siano sempre a 3.4

Le cose son due: o mi sfugge qualcosa o c'è qualcosa che non va (o tutte e due). Inoltre vorrei capire le differenze tra userspace e ondemand. Se non ho capito male ondemand va sempre al minimo oppure al 100% quando c'è bisogno del 100% mentre userspace è un po' più "granulare" a seconda del carico, giusto? Inoltre vorrei capire come dare dei settaggi a mano delle frequenze che funzionino su titti i core e non vadano in conflitto con le policy dei governor (in pratica: che restino come le imposto io finchè reset non sopraggiunga)

denghiu

edit: posto /etc/conf.d/cpufrequtils:

# /etc/conf.d/cpufrequtils: config file for /etc/init.d/cpufrequtils

# Options when starting cpufreq (given to the `cpufreq-set` program)
START_OPTS="--governor userspace" <---- messo io, di default era ondemand

# Options when stopping cpufreq (given to the `cpufreq-set` program)
STOP_OPTS="--governor performance" <---- questo non l'ho capito, a che serve una policy per quando cpufreq si stoppa?? o_o cmq era così e non l'ho toccato

# Extra settings to write to sysfs cpufreq values.
#SYSFS_EXTRA="ondemand/ignore_nice_load=1 ondemand/up_threshold=70"

[k01]

non saprei rispondere con sicurezza sulla prima parte, forse se disabiliti quel core abilitato in più da bios e lasci i 3 di default di fabbrica funziona su tutti e 3 il cambio di frequenza?

per quanto riguarda i governor:

CONFIG_CPU_FREQ_GOV_USERSPACE:
Enable this cpufreq governor when you either want to set the
CPU frequency manually or when a userspace program shall
be able to set the CPU dynamically

userspace è la modalità che ti permette di cambiare manualmente quando vuoi la frequenza del processore, ondemand come hai detto tu cambia la frequenza in base al carico, mandandolo in fretta al 100% se il carico lo richiede, mentre esiste anche conservative, che funziona come ondemand solo in maniera più "lenta", nel senso che per poca richiesta non va subito al 100% ma sale poco alla volta, è indicato per quando si è su un portatile alimentato a batteria.

cpufrequtils è un servizio in init.d, se lo stoppi quella voce riporta il governor all'opzione desiderata

[fbcyborg]

# Options when stopping cpufreq (given to the `cpufreq-set` program)
STOP_OPTS="--governor performance" <---- questo non l'ho capito, a che serve una policy per quando cpufreq si stoppa?? o_o cmq era così e non l'ho toccato

Questa cosa ha sempre incuriosito anche me. Sarei curioso di saperne di più anche io.

[johnnystuff]

non so, tu dici che potrebbe servire disabilitare il 4° core? Sinceramente non credo, perchè gli X3 erano quasi tutti dei normalissimi X4 con un core disabilitato e non difettoso. Da quel che ho letto in giro al tempo quelli con un core difettoso diventavano X2 e pochissimi (con difetti probabilmente minimi) diventavano X3, quindi una volta abilitato da bios il 4° dovrebbe essere un X4 a tutti gli effetti. Sia win che linux infatti lo riconoscono come tale

processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 20 Processor

poi vabbè che l' X4 20 non esiste (era un X3 720 in origine) ma credo che una volta che il kernel riceve dal bios l'informazione che i core sono 4 problemi successivi non ce ne dovrebbero essere e se il 4° core fosse difettoso me ne sarei dovuto accorgere già da tempo, invece tutto perfetto anche in overclock. Inoltre tempo fa cpufreq funzionava e cpuinfo non mi dava l'output per ogni singolo core. Non potrebbe essere un qualche problema in /sys lato kernel per esempio? Una volta sempre se non ricordo male, con cpu0 si intendeva "tutta la cpu" non solo il primo core, o sbaglio?
In ogni caso quello che vorrei capire è se le informazioni date da cpuinfo sono affidabili o lo sono solo quelle relative a cpu0 (inteso quindi alla vecchia maniera come "tutta la cpu"), perchè l'impressione è che non lo sia affatto.

[k01]

non intendevo dire che un core è difettoso, intendevo che magari l'X3 supporta il cambio di frequenza al volo solo su 3 core, con il quarto abilitato il cambio di frequenza non funziona al meglio. ma sono comunque ipotesi mie, nulla di certo

[johnnystuff]

ok forse ho risolto anche se con un piccolo "uorcaraund"

ho scoperto che non c'è un comando solo per cambiare il governor su tutti i core simultaneamente con cpufrequtils. Ecco quindi un simpatico scriptino che lo fa, reiterando quello che dovremmo fare noi a manina per ogni core ogni volta. Come mai cpufreq-set si comporti così è un mistero che mi porterò dietro a lungo ma il man parla chiaro:

REMARKS
Omitting the -c or --cpu argument is equivalent to setting it to zero.

L'autore l'ha chiamato cpufreq-setall.sh. voi fate un po' come volete basta che poi la sintassi sia quella giusta

#!/bin/bash

# Sintax:
# cpufreq-setall.sh <governor>

governor=$1
cores=$(grep -c processor /proc/cpuinfo)
core=0

while [ $core -lt $cores ]; do
cpufreq-set -c $core -g $governor
core=$(($core + 1))
done

basta dargli permessi di esecuzione ovviamente e magari spostarlo in /usr/bin. Per farlo lanciare da un utente qualsiasi, impostare il permesso SUID su cpufreq-set con

chmod u+s /usr/bin/cpufreq-set

Credo che sarebbe abbastanza semplice modificarlo per poter impostare anche le frequenze oltre che il governor, ma non voglio fare figure barbine svelandovi le mie possenti capacità di bash-scripter

[xdarma]

Code: Select all

# Options when stopping cpufreq (given to the `cpufreq-set` program)
STOP_OPTS="--governor performance"  <---- questo non l'ho capito, a che serve una policy per quando cpufreq si stoppa?? o_o cmq era così e non l'ho toccato

Non lo so, forse perché così quando fermi cpufreq, il processore resta disponibile al massimo delle possibilità?
Probabilmente in certe condizioni rischi di trovarti il processore "azzoppato" da un governor "powersave" e non poter richiamare cpufreq-set.
Non che mi vengano in mente degli scenari plausibili, comunque ;-)

ok forse ho risolto anche se con un piccolo "uorcaraund"

Sicuramente il tuo sistema funziona ma hai provato ad usare il flag -r per estendere le impostazioni a tutta la cpu?
Mi chiedevo come mai non fosse già stato adottato come predefinito vista la diffusione dei multicore e ho trovato quella impostazione nella pagina man.

[johnnystuff]

si certo -r l'ho provato ma probabilmente gli autori di cpufrequtils hanno una loro personale comprensione di cosa siano le "hardware related CPUs" (cito dal man) perchè con un #cpufreq-set -r -g powersave (per esempio) il governor viene applicato solo al primo core, praticamente come fa lo stesso comando senza "-r"

[ago]

Moved from Forum italiano (Italian) to Forum di discussione italiano.

[xdarma]

Gironzolando ho trovato questo:
TurionPowerControl
In teoria serve per fare l'undervolting dei Turion/Phenom ma dovrebbe modificare anche le frequenze.