Solaris et mlockall()

Le
JKB
Bonjour à tous,

Toujours avec mon problème de gestion de la mémoire sous Solaris 10.
J'ai lié mon programme avec la libptmalloc3 qui est bien plus
efficace que tous les allocateurs disponibles par défaut sous
Solaris 10. Pour forcer le processus en mémoire (j'ai assez de place
en mémoire), j'ai commencé par coller un

mlockall(MCL_CURRENT|MCL_FUTURE) (qui se passe bien)

au début du programme. Et je perds encore 15 % de mon temps CPU sur
des défauts de pages (information de prstat -av). Effectivement,
lorsque je regarde la sortie d'un prstat tout bête, je peux lire :

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
17778 bertrand 3527M 1792M cpu4 20 0 38:12:18 52% serveur.rpl/66

ce qui me pose problème. Par ailleurs, comment expliquer les défauts
de page pour un processus entièrement en mémoire. Il me semble que
mlockall() verrouille pourtant toutes les pages du processus.

Une idée ?

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
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
JKB
Le #22098621
Le 10-05-2010, ? propos de
Solaris et mlockall(),
JKB ?crivait dans fr.comp.os.unix :
Bonjour à tous,

Toujours avec mon problème de gestion de la mémoire sous Solaris 10.
J'ai lié mon programme avec la libptmalloc3 qui est bien plus
efficace que tous les allocateurs disponibles par défaut sous
Solaris 10. Pour forcer le processus en mémoire (j'ai assez de place
en mémoire), j'ai commencé par coller un

mlockall(MCL_CURRENT|MCL_FUTURE) (qui se passe bien)

au début du programme. Et je perds encore 15 % de mon temps CPU sur
des défauts de pages (information de prstat -av). Effectivement,
lorsque je regarde la sortie d'un prstat tout bête, je peux lire :

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
17778 bertrand 3527M 1792M cpu4 20 0 38:12:18 52% serveur.rpl/66

ce qui me pose problème. Par ailleurs, comment expliquer les défauts
de page pour un processus entièrement en mémoire. Il me semble que
mlockall() verrouille pourtant toutes les pages du processus.

Une idée ?



En fait, je viens de relire la doc et un point me chagrine. Sous
Linux, il est écrit que mlockall() verrouille _toutes_ les pages en
mémoire. Sous Solaris, on parle de "mapped pages". Question :
quelqu'un peut-il confirmer (ou informer) que le mlockall() de
solaris verrouille _aussi_ les zones allouées par malloc() ou sbrk() ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
debug this fifo
Le #22099581
JKB wrote:

mémoire. Sous Solaris, on parle de "mapped pages". Question :
quelqu'un peut-il confirmer (ou informer) que le mlockall() de
solaris verrouille _aussi_ les zones allouées par malloc() ou sbrk() ?



hypothèse àlc:
quand tu alloues ta memoire (quel que soit le moyen), les pages ne sont
pas mappées. en lecture tu as des 0, et si tu écris dedans, ya fault
et la tripaille dans la cave de l'OS va mapper à ce moment. il faut
dont 'utiliser' ces zones mémoires avant de les verrouiller.
JKB
Le #22099691
Le 11-05-2010, ? propos de
Re: Solaris et mlockall(),
debug this fifo ?crivait dans fr.comp.os.unix :
JKB wrote:

mémoire. Sous Solaris, on parle de "mapped pages". Question :
quelqu'un peut-il confirmer (ou informer) que le mlockall() de
solaris verrouille _aussi_ les zones allouées par malloc() ou sbrk() ?



hypothèse àlc:
quand tu alloues ta memoire (quel que soit le moyen), les pages ne sont
pas mappées. en lecture tu as des 0, et si tu écris dedans, ya fault
et la tripaille dans la cave de l'OS va mapper à ce moment. il faut
dont 'utiliser' ces zones mémoires avant de les verrouiller.



Ça, je veux bien. Ce que je ne comprends pas, c'est l'utilité de
MCL_FUTURE dans l'appel mlockall(). Mon algorithme fait des tas
d'allocations (et de libération) de la mémoire. J'aimerais qu'il
alloue et libère directement de la mémoire et non du swap.
MCL_FUTURE est censé permettre un verrouillage du processus en
mémoire. Visiblement, il alloue toujours sur le swap et mettrait les
pages en mémoire à la première écriture ? C'est idiot... Et je ne
comprends toujours pas pourquoi ce @#{^ de Solaris utilise le swap
alors que j'ai plus de 4 Go de disponible !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Éric Lévénez
Le #22099891
Le 10/05/10 22:36, JKB a écrit :
Il me semble que
mlockall() verrouille pourtant toutes les pages du processus.



Avec google, j'ai trouvé la doc suivante sur Solaris 10 : "If the
process calls mloackall(3C) with MCL_FUTURE flag, the pages mapped by
all future calls to mmap() will be locked in memory.". D'après ce que tu
décris, Solaris verrouille uniquement les pages allouées par mmap at pas
par sbrk. Si c'est bien le cas, il faudrait utiliser un malloc qui
utilise mmap et pas sbrk.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
JKB
Le #22099931
Le 11-05-2010, ? propos de
Re: Solaris et mlockall(),
Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 10/05/10 22:36, JKB a écrit :
Il me semble que
mlockall() verrouille pourtant toutes les pages du processus.



Avec google, j'ai trouvé la doc suivante sur Solaris 10 : "If the
process calls mloackall(3C) with MCL_FUTURE flag, the pages mapped by
all future calls to mmap() will be locked in memory.". D'après ce que tu
décris, Solaris verrouille uniquement les pages allouées par mmap at pas
par sbrk. Si c'est bien le cas, il faudrait utiliser un malloc qui
utilise mmap et pas sbrk.



En l'occurrence, j'utilise ptmalloc3 parce que les malloc par défaut
ne conviennent pas (ce sont des first fit qui font exploser la
mémoire virtuelle, sauf mtmalloc qui est un best fit mais pas
optimal du tout...). Je n'ai pas l'impression qu'il utilise sbrk().
En tout cas, il n'y a pas d'appel à sbrk depuis la bibliothèque. Je
vais essayer de forcer la chose en forçant ptmalloc3 à utiliser
mmap().

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
xavier
Le #22103951
JKB
il alloue toujours sur le swap et mettrait les
pages en mémoire à la première écriture



calloc() c'est POSIX ?

Parce que ça va peut être te prendre un pouillème de CPU de mettre à
zéro les zones allouées, mais si ça te garantit leur présence en mémoire
physique, c'est tout bénef...

J'ai le souvenir, il y a fort longtemps, d'avoir été confronté au même
problème, réglé par l'utilisation de calloc() au lieu de malloc(), mais
j'ai trop honte d'avouer l'OS concerné :-)

J'avais d'ailleurs du réécrire un allocateur pour la bouze en question.

--
XAv - recasé
JKB
Le #22104811
Le 11-05-2010, ? propos de
Re: Solaris et mlockall(),
Xavier ?crivait dans fr.comp.os.unix :
JKB
il alloue toujours sur le swap et mettrait les
pages en mémoire à la première écriture



calloc() c'est POSIX ?



M'en fiche, j'ai déjà dû utiliser ptmalloc3 tellement les
performances des allocateurs par défaut de Solaris sont moisies.
ptmalloc3 fournit un calloc().

Parce que ça va peut être te prendre un pouillème de CPU de mettre à
zéro les zones allouées, mais si ça te garantit leur présence en mémoire
physique, c'est tout bénef...

J'ai le souvenir, il y a fort longtemps, d'avoir été confronté au même
problème, réglé par l'utilisation de calloc() au lieu de malloc(), mais
j'ai trop honte d'avouer l'OS concerné :-)



Des noms, des noms, des noms ;-)

J'avais d'ailleurs du réécrire un allocateur pour la bouze en question.



HP-UX ? J'ai des souvenirs comme ça...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Publicité
Poster une réponse
Anonyme