Re: [Discuss-gnuradio] Shared Memory Confusion

[Philip Balister]

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 <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
>