Re: pulseaudio
Le Sun, 8 Mar 2009 02:19:23 +0100 (CET)
Jeep <djepi@wanadoo.fr> a écrit:
> [...]
> > > je ne me souviens plus à quoi correspondent les valeurs
> > > des vars exactement.
> > > Mais tout est là :
> > > 'man pulse-daemon.conf'
> >
> > Oui et non, ils n'expliquent pas la signification des valeurs. Par
> > exemple ça ne dit pas ce que veux dire -1 pour memlock
> Oui, mais ils disent *aussi* que si tu veux plus de détails, il faut
> faire ça :
> 'man 2 getrlimit'
Ah oui! Mais comme j'avais une recherche directement sur l'option je
n'avais pas vu cette partie.
Bon d'un autre côté man 2 getrlimit ne donne rien chez moi... :(
> Et là, *entre autres* :
>
> RLIMIT_MEMLOCK
> Le nombre maximal d’octets de mémoire virtuelle que le processus peut
> verrouiller en RAM. En pratique cette limite est arrondie vers le bas
> au multiple de la taille de page le plus proche. Cette limite affecte
> mlock(2) et mlockall(2) ainsi que l’opération MAP_LOCKED de mmap(2).
> Depuis Linux 2.6.9, elle affecte aussi l’opération SHM_LOCK de shmctl
> (2), où elle limite le nombre total d’octets dans des segments de
> mémoire partagée (voir shmget(2)) que l’UID réel du processus
> appelant peut verrouiller. Les verrous de shmctl(2) SHM_LOCK sont
> comptés séparément des verrous de mémoire par processus établis par
> mlock(2), mlockall(2) et mmap(2) MAP_LOCKED ; un processus peut
> verrouiller des octets jusqu’à la limite dans chacune de ces
> catégories. Dans les noyaux antérieurs à 2.6.9, cette limite
> contrôlait la quantité de mémoire qu’un processus privilégié pouvait
> verrouiller. Depuis Linux 2.6.9, un processus privilégie peut
> verrouiller autant de mémoire qu’il le souhaite, et cette limite
> contrôle la quantité de mémoire pouvant être verrouillée par un
> processus non privilégié.
>
> >
> > Dois manquer un petit lien, non? ;)
> Arf ... ben j'aurais juré qu'il y était !?!
> Gasp, le v'la :
>
Ah ben non il n'est toujours pas là... :)
A+
Gaëtan
Reply to: