Re: pulseaudio
[...]
> > > Non je n'y ai pas touché j'ai juste le high-priority
> > Oui mais non, je fatigue là, c'est 'high-priority' l'important,
> > le no-scheduling ne devrait pas générer tes messages d'erreur.
>
> Me too, d'ailleurs je vais aller voir morphée ;)
Oué, tu as raison, il se fait tar^H^H^Htôt ! ;)
Alors on se retrouve là-bas !? :)
[...]
> > 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'
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 :
Simple.
>
> Bonne nuit.
Merci, à toi aussi !
Jeep.
Reply to: