On 11/26/2014 09:30 AM, Marcus Müller wrote: > 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?
And the answers are here: https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/vmcircbuf.cc#L104 If there is interest, I'll send in a patch to move: result.push_back (gr::vmcircbuf_mmap_tmpfile_factory::singleton()); to the top of the list of factories. Philip > > 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 > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
