Occupation memoire negative ("ps")

Le
Olivier Croquette
Salut

C'est super, je viens de me rendre compte que j'ai des processus qui me
rajoutent de la mémoire :)

mbp:~ ocroquette$ ps aux | head
USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND
windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L
xxx 763 1.0 -0.6 372780 11660 ?? S 0:02.36 /Applicat
xxx 247 0.5 -0.4 374180 7980 ?? S 0:34.07 /System/L
root 25 0.0 -0.2 31796 4672 ?? Ss 0:05.23 kextd
root 55 0.0 -0.0 27248 184 ?? S+ 0:00.00 /usr/libe
root 58 0.0 -0.0 27824 612 ?? Ss 0:00.01 /System/L
root 59 0.0 -0.0 27844 524 ?? Ss 0:00.02 /usr/sbin
root 60 0.0 -0.0 28016 972 ?? Ss 0:00.33 /usr/sbin
root 61 0.0 -0.0 27580 572 ?? Ss 0:00.35 /usr/sbin

J'ai pas cherché la cause, mais il doit y avoir un bug qqpart
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Levenez
Le #18069871
Le 07/12/08 12:07, dans Croquette »
mbp:~ ocroquette$ ps aux | head
USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND
windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L
xxx 763 1.0 -0.6 372780 11660 ?? S 0:02.36 /Applicat
xxx 247 0.5 -0.4 374180 7980 ?? S 0:34.07 /System/L
root 25 0.0 -0.2 31796 4672 ?? Ss 0:05.23 kextd
root 55 0.0 -0.0 27248 184 ?? S+ 0:00.00 /usr/libe
root 58 0.0 -0.0 27824 612 ?? Ss 0:00.01 /System/L
root 59 0.0 -0.0 27844 524 ?? Ss 0:00.02 /usr/sbin
root 60 0.0 -0.0 28016 972 ?? Ss 0:00.33 /usr/sbin
root 61 0.0 -0.0 27580 572 ?? Ss 0:00.35 /usr/sbin

J'ai pas cherché la cause, mais il doit y avoir un bug qqpart...



Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
Olivier Croquette
Le #18073491
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?



MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
qq part dans le code :)
Eric Levenez
Le #18074021
Le 07/12/08 19:15, dans Croquette »
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?



MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
qq part dans le code :)



Il faudrait, bien entendu, faire un bug report à Apple.

D'après ce que je comprends la fonction task_info du noyau est différente
sur un CPU intel 32 et 64 bits. En 32 bits (je suppose que c'est ce que tu
as vu que tu n'en parles pas), la taille mémoire est stockée dans un
"unsigned int" (si l'on se réfère aux includes), ce qui n'est pas bon car
avec 4 Go de RAM, on obtiendrait 0. Mais d'un autre côté à d'autres endroits
du noyau cette taille est calculée en page, donc, aucun problème, si c'est
bien fait. Avec un CPU 64 bits, pas de problème car les calculs sont faits
en 64 bits non signés. La commande ps, elle, fait une conversion de ces
nombres non signés en flottants pour affichage, alors je ne pense pas que le
bug soit dans "ps".

Bref, le mieux est de faire un bug report, car eux auront le temps de
trouver le problème...

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
Anonyme
Le #18079781
Eric Levenez
Le 07/12/08 19:15, dans Croquette »
> Eric Levenez wrote, On 7/12/08 12:52:
>> Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
>> version du système ? Que donne "top" ?
>
> MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
> qq part dans le code :)

Il faudrait, bien entendu, faire un bug report à Apple.



Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...

--
Anonyme ( jayce <@> mosx.org )
********* MosX.org Ce message est sous licence Creative Commons "by-nc-sa-2.0"
fx [François-Xavier Peretmere]
Le #18082251
On 08/12/2008 12:50, Anonyme wrote:
Eric Levenez
Le 07/12/08 19:15, dans Croquette »
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?


MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
qq part dans le code :)


Il faudrait, bien entendu, faire un bug report à Apple.



Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...



Exact. Mais normalement, les Go supplémentaires sont simplement ignorés - du
moins c'est ce que j'avais lu à l'époque. Je n'ai pas testé, j'ai acheté une
barrette de 1 Go du coup.

Je ne pense pas que cela expliquerait la mémoire négative. Bien qu'il suffirait
d'en ôter une pour tester.

--
Fx, quatriéme jour sans MBP. It's a hard life without the little retarded.
Olivier Croquette
Le #18085631
Anonyme wrote, On 8/12/08 12:50:
Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...



Oui, c'est un MBP mid 2007.
Version du système : Mac OS X 10.4.11 (8S2167)
Version du noyau : Darwin 8.11.1
manet
Le #18086151
"fx [François-Xavier Peretmere]"
> Attention toute fois à s'assurer que le MBP en question est bien sensé
> supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
> selon Apple...

Exact. Mais normalement, les Go supplémentaires sont simplement ignorés -



il faudrait savoir comment le chipset fonctionne.

d'après ce que j'ai lu, quand on met d 2 x 2 G sur les machines dont le
chipset Intel est limité à 3G
- sur Tiger, le système voit 3G
- sur Leo, le système en voit 4.

mais dans tous les cas, le système ne sait pas allouer plus de 3,xxx G,
avec xxx du coté de 600 MO ou 000 selon les sources

cependant, on bénéficie de la parité des barrettes, qui accélére le
transfert RAM. Le processeur ne sachant pas bénéfiier de cette parité,
ce serait uniquement le processeur graphique (qui utilise la RAM) qui
gagnerait en vitesse ; le bénéfice dépend donc largement du type
d'utilisation.

Les tests de base trouvent 3 à 5% en mieux (3G vs 4G) sur OWC, si je me
souviens bien.
laurent.pertois
Le #18086741
Philippe Manet
ce serait uniquement le processeur graphique (qui utilise la RAM) qui
gagnerait en vitesse ; le bénéfice dépend donc largement du type
d'utilisation.



Pas sur un MacBook Pro qui a une carte graphique (encore que pour les
derniers il faut voir vu que ce dernier a 2 systèmes)

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Olivier Croquette
Le #18107291
Olivier Croquette wrote, On 7/12/08 12:07:
mbp:~ ocroquette$ ps aux | head
USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND
windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L

J'ai pas cherché la cause, mais il doit y avoir un bug qqpart...



Pour info, la réponse d'Apple:

This is a follow up to Bug ID# 6426376. After further investigation it
has been determined that this is a known issue, which is currently being
investigated by engineering. This issue has been filed in our bug
database under the original Bug ID# 3118432. The original bug number
being used to track this duplicate issue can be found in the State
column, in this format: Duplicate/OrigBug#.

Thank you for submitting this bug report. We truly appreciate your
assistance in helping us discover and isolate bugs.
Publicité
Poster une réponse
Anonyme