Hi Everybody, I had a very interesting dive into vmcircbuffer_sysv_shm today. Questions that arose from that are: a) why is a SYSV circbuffer implementation the default one on my linux 3.17 box? b) SYSV shared memory segments have a flag that should tell the OS to release the segment as soon as its global reference count goes to 0. If I read vmcircbuffer_sysv_shm.cc correctly, it's not getting set for all segments. That is what could have caused Felix' problems. Is that a bug? c) I think I might need someone to explain to me why our circular buffers depend on shared memory -- can't one just mmap() anonymously without generating shared memory handles underneath? d) what's the order in which circbuffer implementations are chosen?
Greetings, Marcus On 11/25/2014 07:28 PM, Felix W. wrote: > That fixed it! Thanks!! > > 2014-11-25 18:48 GMT+01:00 Marcus Müller <[email protected]>: > > Does increasing kernel.shmmni using sysctl to let's say 16k improve > the situation? > > On 11/25/2014 06:37 PM, Marcus Müller wrote: > >>> Hi Felix, > >>> > >>> > >>> On 11/25/2014 06:15 PM, Felix W. wrote: > >>>> Between every run, I call tb.stop() followed by tb.wait(). > >>>> Unfortunately, after a few runs (around 20), I get the following > >>>> error message: > >>> > >>>> gr::vmcircbuf_sysv_shm: shmget (2): No space left on device > >>> I have a suspicion. First of all, I know this sounds basic, but > >>> you're not using a 32bit GR on your 64 bit machine, are you? (that > >>> would explain running out of RAM faster, just because process > >>> memory is so very limited for 32bit processes) > >>> > >>> then: vmcircbuf is one of the things I always was kind of hesitant > >>> to touch (or even try to understand in depth), just because it > >>> deals with a lot of POSIX/OS specifics that I'm not an expert in, > >>> but: > >>> > >>> Maybe tb.stop()/wait doesn't actually successfully unmap the > >>> shared memory segments of the buffers; there's a global maximum of > >>> segments, and it 4096 by default (/proc/sys/kernel/shmmni). > >>> However, this shouldn't be the problem at hand: there's an error > >>> number for this condition. And it would be: ENOSPC. Great. The same > >>> thing as for "No space left on device"; Thank you, Posix.1... > >>> > >>> Cheers, Marcus > >>> > >>> _______________________________________________ Discuss-gnuradio > >>> mailing list [email protected] > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
