discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Memory allocation woes


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Memory allocation woes
Date: Tue, 29 Jun 2010 15:56:09 -0700
User-agent: Mutt/1.5.20 (2009-08-17)

On Tue, Jun 29, 2010 at 02:16:24PM -0400, Marcus D. Leech wrote:
> On 06/29/2010 01:37 PM, Eric Blossom wrote:
> > The place to add some debugging outout would be
> > gr_flat_flowgraph.cc::allocate_buffer.  Something like:
> >
> >   std::cout << "allocate_buffer " << block
> >             << " nitems " << nitems << " item_size " << item_size << 
> > std::endl;
> >
> >
> > For the case of the 6M bin FFT, I could see us getting to
> >
> >   6M * sizeof(gr_complex) * 2 * 2 --> 192MB.  Not that big.
> >
> >
> > Add the debugging output and let us know what you find.
> >
> >   
> allocate_buffer complex_to_mag(1) nitems 4 item_size 25000000
> gr_buffer::allocate_buffer: warning: tried to allocate
>    4 items of size 25000000. Due to alignment requirements
>    64 were allocated.  If this isn't OK, consider padding
>    your structure to a power-of-two bytes.
>    On this platform, our allocation granularity is 4096 bytes.
> gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
> gr_buffer::allocate_buffer: failed to allocate buffer of size 1562500 KB
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> 
> 
> This is the complex_to_mag(1) right after the HUGE FFT.
> 
> That item size must be the size of the *output* vector (6M *
> sizeof(float) + 'slop'??).

There won't be any slop in the item_size.  That comes from the
io_signature.  25,000,000/sizeof(gr_complex) = 3,125,000.  Does that sound 
familiar?
It must be the number of bins in the FFT.

> Now, see what happens?  It's rounding up that 4 items to 64 items, which
> is ballooning out
>   the request size considerably!!

If you pick a size with more factors of 2 and fewer factors of 5, life
will get better :-)

I have on occasion thought that it would be a good idea to switch to
an alternate circular buffer strategy when the size blows up too much
because of the alignment requirement.  The alternate would probably
use memcpy to duplicate the appropriate portion of the buffer on
return from general_work instead of the MMU trick.  I probably won't
get to it this lifetime, but if you're interested, let me know and
I'll give you my ideas on how to go about it.

Eric



reply via email to

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