Re: [Tsp-devel] Increasing memory while sampling

[Eric Noulard]

Le 30/07/07, Eric Noulard<address@hidden> a écrit :
> > Est-ce qu'on pourrait avoir le problème suivant:
> > 1) RINGBUF_PTR_INIT alloue beaucoup de mÃmoire en dÃ(c)but de programme:
> > cf: http://www.mail-archive.com/address@hidden/msg00480.html
> > - massif rapporte une alloc de 1Go!

Après une analyse sommaire je pense qu'il y a mésinterprétation sur
ce que dit massif.
Je pense que les 1 Go sont des 1000 000 0000 ms.B

cf:
All measurements are done in spacetime, i.e. space (in bytes)
multiplied by time (in milliseconds).
http://valgrind.org/docs/manual/ms-manual.html

Avec les mêmes tests je tombes sur l'allocation d'un ringbuffer de
grosso-modo 24Mo
RINGBUF_PTR_INIT request 23437 Kbytes
(sizeof(TSP_sample_ringbuf_t)=32,sizeof(TSP_sample_t)=24,mul_offset=1,sz=1000004)

soit en gros  "24 * 1000004" qui est la taille d'un sample (TSP_sample_t)
multiplié par notre "estimation maison" de 1000 sample à 100 Hz pendant 10 sec
1000*100*10 --> 1000000 (+4 qui vient d'un arrondi)


> > 2) L'allocation marche, mais les pages ne sont utilisÃ(c)es effectivement
> > qu'au fur et a mesure, du coup on a l'impression que les allocations se
> > font de manière continue et a un rythme elevÃ(c).
>
> C'est possible.
> Je m'en vais ajouter un mlockall histoire de voir si ça me pète à la tronche.

Le mlockall ne pète pas  et me locke (de façon durable et sans augmentation)
à peu près 60 Mo de mémoire....
cf cat /proc/<pid_ascii_writer>/status donne:
-----------------------------------
Name:   tsp_ascii_write
State:  S (sleeping)
SleepAVG:       98%
Tgid:   32512
Pid:    32512
PPid:   3237
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0 1 2 3 4 5 6 7 8 9 10 12
VmPeak:    62736 kB
VmSize:    62736 kB
VmLck:     62736 kB
VmHWM:     38208 kB
VmRSS:     38208 kB
VmData:    34416 kB
VmStk:        88 kB
VmExe:        12 kB
VmLib:      3544 kB
VmPTE:       168 kB
StaBrk: 00603000 kB
Brk:    00624000 kB
StaStk: 7fff686bbe60 kB
Threads:        2
SigQ:   1/16368
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000002
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
Cpus_allowed:   00000000,000000ff
Mems_allowed:   00000000,00000001
------------------------
>
> > 3) On n'aurait pas de problème de fuite mÃ(c)moire mais juste un ring
> > buffer trop gros en comparaison avec ce dont on a rÃ(c)ellement besoin?
>
> Oui, possible.
> J'avais déjà limité la taille de certains buffers à 2 Mo.
> https://savannah.nongnu.org/bugs/index.php?16629
>
> Je vais voir ce que je peux faire pour le ringbuf.
> Ce qui est étonnant c'est qu'un deuxième tsp_sample_request_init
> stoppe le phénomène.

Le taillage du ringbuf côté consumer est probablement surdimensionné
et je vais tenter d'améliorer ça en utilisant les infos de la
request_sample plutôt que l'abaque 1000 symboles/100Hz/10secondes...

Néanmoins LE PROBLEME reste entier JE NE VOIS PAS d'OU VIENT
LA FUITE !!!

-- 
Erk