discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Shared Memory Confusion (was: Running out of memory d


From: Marcus Müller
Subject: [Discuss-gnuradio] Shared Memory Confusion (was: Running out of memory during BER simulations)
Date: Wed, 26 Nov 2014 15:30:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]