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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JKB
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.
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.
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
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 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.
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 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.
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.
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 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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
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 -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
JKB
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.
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.
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
JKB wrote:
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 <knatschke@koenigsberg.fr> wrote:
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.
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 11-05-2010, ? propos de Re: Solaris et mlockall(), Xavier ?crivait dans fr.comp.os.unix :
JKB wrote:
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.
Le 11-05-2010, ? propos de
Re: Solaris et mlockall(),
Xavier ?crivait dans fr.comp.os.unix :
JKB <knatschke@koenigsberg.fr> wrote:
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.
Le 11-05-2010, ? propos de Re: Solaris et mlockall(), Xavier ?crivait dans fr.comp.os.unix :
JKB wrote:
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.
