[PD-dev] memory locking policy

[Tim Blechmann]

hi developers ...

currently pd in -rt mode tries to lock the memory to the physical memory
... this is done using the MCL_FUTURE policy, which implies that all the
memory that will be allocated in future will be placed in the physical
memory ...
at the moment this is working fine, but when hunting random segfaults in
the threaded soundfiler, i found this note in the mlockall man-page:

>        If  MCL_FUTURE  has  been  specified and the number of locked
>        pages exceeds the upper limit of allowed locked pages, then the
>        system call which caused the new mapping will fail with ENOMEM.
>        If  these new pages have been mapped by the the growing stack,
>        then the kernel will deny stack expansion and send a SIGSEGV.

to me this seems to be the reason for the soundfiler problems, but it
can reduce the stability of a working patch, so i'd suggest to find ways
to solve this problem ...

possible ideas:
-run mlockall(MCL_CURRENT) every once in a while ... maybe after a new
object has been created or each second, 10 seconds, 1e+(add a number
here) a seconds ...

-lock the specific memory region while allocating in getbytes or
getalignedbytes

-on linux it might be possible to switch of overcommitment of memory in
the kernel via /proc/sys/vm/overcommit_memory (don't know if this really
does, what i think it's doing)

imo, MCL_FUTURE shouldn't be used to avoid this source of error ...
although i'm not sure how to deal with it best, i'd prefer mlock
instructions during memory allocation ...

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs