Je fais tourner mon MacBook Pro de façon assez costaud ces
derniers temps (genre trouver le BPM de mes dizaines de milliers de
titres) et je ne suis pas forcément pressé. Je peux le laisser tourner
une nuit au lieu d'une heure par exemple.
Je dis ça parce qu'avec le temps qu'il fait j'ai les
ventilateurs à fond et si le clavier était mieux conçu je pourrai faire
cuire mes ½ufs dessus ;-)
Alors peut-on limiter la consommation de CPU d'une appli ? Et ce
juste pour quelques heures pas advitam.
D'avance merci.
PS j'ai actuellement BPMer.app qui tourne à 92% d'un core et
donc...
--
Benoît http://picasaweb.google.com/leraillez/
Avec des fumeurs c'est difficile de s'arrêter. Avec des branleurs,
là, par contre, c'est difficile de continuer.
In article <1jl3oij.i8hdyxoqlveiN%, (Olivier Marti) wrote:
J.P wrote:
> In article <1jl2pv0.1v39wkqi1ku8N%, > (JiPaul) wrote: > > > Olivier Marti wrote: > > > > > renice va diminuer la priorité du processus. Mais le processus est le > > > seul a réclamer du CPU, il va quand même tourner à 100% ! (?) > > > > Heuuuh !... N'est-ce pas ce que j'ai dit ? :-/ > > Très intéressante discussion mais le sujet initial était: " Je dis > ça parce qu'avec le temps qu'il fait j'ai les ventilateurs à fond et si le > clavier était mieux conçu je pourrai faire cuire mes ½ufs dessus ;-)" et > donc, moins geek, je reviens à la solution "blocs congelés" et/ou > aspirateur. C'est bruyant, mais avec un programateur sur la prise de > l'aspirateur, c'est très très con, mais ça refroidit: juré !!! :-) > > Jean-Pierre
L'aspirateur fait vraiment moins de bruit que les ventilateurs du mac ... ??
Sinon, mettre la machine dans le frigo peut-être efficace. Mais j'aurais un peu peur que du givre se forme sur les composants .. ?
Olivier
On peut en rire, mais ça m'a permis de fonctionner 2 mois en attendant que Maintronic récupère une carte graphique puis un disque dur pour mon iMac qui sur chauffait.
Par ailleurs, ralentir le CPU n'est pas nécessairement adéquat vu que ce qui chauffait le plus dans mon cas c'est la carte graphique et l'alim.
JP
In article <1jl3oij.i8hdyxoqlveiN%olivier.marti@ensta.org>,
olivier.marti@ensta.org (Olivier Marti) wrote:
J.P <jpp@gmail.com> wrote:
> In article <1jl2pv0.1v39wkqi1ku8N%blanc@empty.org>, blanc@empty.org
> (JiPaul) wrote:
>
> > Olivier Marti <olivier.marti@ensta.org> wrote:
> >
> > > renice va diminuer la priorité du processus. Mais le processus est le
> > > seul a réclamer du CPU, il va quand même tourner à 100% ! (?)
> >
> > Heuuuh !... N'est-ce pas ce que j'ai dit ? :-/
>
> Très intéressante discussion mais le sujet initial était: " Je dis
> ça parce qu'avec le temps qu'il fait j'ai les ventilateurs à fond et si le
> clavier était mieux conçu je pourrai faire cuire mes ½ufs dessus ;-)" et
> donc, moins geek, je reviens à la solution "blocs congelés" et/ou
> aspirateur. C'est bruyant, mais avec un programateur sur la prise de
> l'aspirateur, c'est très très con, mais ça refroidit: juré !!! :-)
>
> Jean-Pierre
L'aspirateur fait vraiment moins de bruit que les ventilateurs du mac
... ??
Sinon, mettre la machine dans le frigo peut-être efficace. Mais j'aurais
un peu peur que du givre se forme sur les composants .. ?
Olivier
On peut en rire, mais ça m'a permis de fonctionner 2 mois en attendant que
Maintronic récupère une carte graphique puis un disque dur pour mon iMac qui sur
chauffait.
Par ailleurs, ralentir le CPU n'est pas nécessairement adéquat vu que ce qui
chauffait le plus dans mon cas c'est la carte graphique et l'alim.
In article <1jl3oij.i8hdyxoqlveiN%, (Olivier Marti) wrote:
J.P wrote:
> In article <1jl2pv0.1v39wkqi1ku8N%, > (JiPaul) wrote: > > > Olivier Marti wrote: > > > > > renice va diminuer la priorité du processus. Mais le processus est le > > > seul a réclamer du CPU, il va quand même tourner à 100% ! (?) > > > > Heuuuh !... N'est-ce pas ce que j'ai dit ? :-/ > > Très intéressante discussion mais le sujet initial était: " Je dis > ça parce qu'avec le temps qu'il fait j'ai les ventilateurs à fond et si le > clavier était mieux conçu je pourrai faire cuire mes ½ufs dessus ;-)" et > donc, moins geek, je reviens à la solution "blocs congelés" et/ou > aspirateur. C'est bruyant, mais avec un programateur sur la prise de > l'aspirateur, c'est très très con, mais ça refroidit: juré !!! :-) > > Jean-Pierre
L'aspirateur fait vraiment moins de bruit que les ventilateurs du mac ... ??
Sinon, mettre la machine dans le frigo peut-être efficace. Mais j'aurais un peu peur que du givre se forme sur les composants .. ?
Olivier
On peut en rire, mais ça m'a permis de fonctionner 2 mois en attendant que Maintronic récupère une carte graphique puis un disque dur pour mon iMac qui sur chauffait.
Par ailleurs, ralentir le CPU n'est pas nécessairement adéquat vu que ce qui chauffait le plus dans mon cas c'est la carte graphique et l'alim.
Un autre moyen est de faire kill SIGSTOP puis SIGCONT de façon cyclique (genre toutes les secondes),
Oui, bien sûr...
mais cela peut avoir des effets de bord si l'application n'a pas bien prévu cela.
Quel genre d'effet de bord ? Le fait de faire kill SIGSTOP/SIGCONT n'est-il pas équivalent (pour l'appli) aux suspensions qu'elle subit du fait de l'ordonnancement ?
Pour SIGSTOP je n'en suis pas sûr, peut-être qu'il n'y a pas d'effets de bord. Pour SIGTSTP qui est pratiquement la même chose (généralement envoyé par Ctrl-Z), c'est sûr qu'il y a des effets de bord sous Mac OS X : les appels systèmes retournent EINTR.
Par exemple <http://www.webgroupes.eu/thread-67-0-40688-296/ctrl-z.htm>
La réaction à un SIGTSTP est modifiable alors que le comportement associé à SIGSTOP ne l'est pas. Dans les deux cas, à la reprise, lors de la réception du SIGCONT, certains appels systèmes peuvent retourner EINTR.
Le scheduleur (qui réalise l'ordonnancement) n'envoie jamais de signal au processus lui-même. Ce n'est donc pas équivalent à SIGSTOP/SIGCONT...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Un autre moyen est de faire kill SIGSTOP puis SIGCONT de façon cyclique
(genre toutes les secondes),
Oui, bien sûr...
mais cela peut avoir des effets de bord si
l'application n'a pas bien prévu cela.
Quel genre d'effet de bord ? Le fait de faire kill SIGSTOP/SIGCONT
n'est-il pas équivalent (pour l'appli) aux suspensions qu'elle subit du
fait de l'ordonnancement ?
Pour SIGSTOP je n'en suis pas sûr, peut-être qu'il n'y a pas d'effets
de bord. Pour SIGTSTP qui est pratiquement la même chose (généralement
envoyé par Ctrl-Z), c'est sûr qu'il y a des effets de bord sous Mac OS
X : les appels systèmes retournent EINTR.
Par exemple <http://www.webgroupes.eu/thread-67-0-40688-296/ctrl-z.htm>
La réaction à un SIGTSTP est modifiable alors que le comportement
associé à SIGSTOP ne l'est pas. Dans les deux cas, à la reprise, lors de
la réception du SIGCONT, certains appels systèmes peuvent retourner
EINTR.
Le scheduleur (qui réalise l'ordonnancement) n'envoie jamais de signal
au processus lui-même. Ce n'est donc pas équivalent à SIGSTOP/SIGCONT...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Un autre moyen est de faire kill SIGSTOP puis SIGCONT de façon cyclique (genre toutes les secondes),
Oui, bien sûr...
mais cela peut avoir des effets de bord si l'application n'a pas bien prévu cela.
Quel genre d'effet de bord ? Le fait de faire kill SIGSTOP/SIGCONT n'est-il pas équivalent (pour l'appli) aux suspensions qu'elle subit du fait de l'ordonnancement ?
Pour SIGSTOP je n'en suis pas sûr, peut-être qu'il n'y a pas d'effets de bord. Pour SIGTSTP qui est pratiquement la même chose (généralement envoyé par Ctrl-Z), c'est sûr qu'il y a des effets de bord sous Mac OS X : les appels systèmes retournent EINTR.
Par exemple <http://www.webgroupes.eu/thread-67-0-40688-296/ctrl-z.htm>
La réaction à un SIGTSTP est modifiable alors que le comportement associé à SIGSTOP ne l'est pas. Dans les deux cas, à la reprise, lors de la réception du SIGCONT, certains appels systèmes peuvent retourner EINTR.
Le scheduleur (qui réalise l'ordonnancement) n'envoie jamais de signal au processus lui-même. Ce n'est donc pas équivalent à SIGSTOP/SIGCONT...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
