On 11/26/2014 03:30 PM, 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?
Despite what the header says, the sysv implementation doesn't call mmap(). Which I say with a 80% confidence, because that's as far as I'll go with the circbuff stuff. > 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 > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
