Re: [Discuss-gnuradio] Shared Memory Confusion

[Martin Braun]

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 <address@hidden>:
>>
>> 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 address@hidden
>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>