Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief

[Michael Dickens]

One should be able to pretty easily do a single buffer (map or not), or double 
map buffer.  Either way, one needs to check for wrap.

The former (single buffer), as Josh states, requires a memory copy every so 
often (when wrap happens).  There is a trade-off between buffer allocation size 
and how often memory copies are required: bigger buffer memory allocations mean 
less frequent memory copies (wrap less often).  The single buffer can be 
implemented via a memory map or some other user-space means, depending on how 
the application is created (e.g., as multiple processes or threads).  A benefit 
of having this buffer available is that not all computation devices support 
memory maps (e.g., current GPUs, many DSPs) -- but, the trend is towards 
support in the future if you believe what NVIDIA, Intel, and AMD/ATI are 
presenting (shared memory between the various SoC processors, allowing for 
dynamic runtime memory maps between any and/or all of them).

The latter avoids the memory copy at wrap time, and the buffer allocation can 
be as small as possible.  Because the buffer allocation must be in kernel 
memory & hence a multiple of pagesize(), there is a limit to how small it can 
be.  But, avoiding the copy will reduce overhead time -- which was, I bet, the 
original goal in creating the double map buffer. - MLD

On Jul 3, 2011, at 4:07 AM, Josh Blum wrote:
> Suppose that we didn't have a specially mapped memory. I believe the
> scheduler could easily ensure that contiguous chunks of memory are
> always passed into the work function with little overhead for both read
> and for write.
> 
> Now, I bet there will be a slight problem when you have a block with
> "history" like FIR filter that needs ntaps worth of samples repeated
> into the next work function. So, when the scheduler has to actually wrap
> back around to the beginning of the buffer, it will have to memcpy
> nsamps to the begging of the buffer. Which shouldnt be bad when buffer
> size >>> history size.
> 
> Its sounds possible (so stop me if I missed something big here).
> Basically, it would be nice to support a linear memory/buffer mode for
> the block executor for two reasons. 1) switch to a linear memory when
> allocation of mapping fails, and 2) swap out the buffer with something
> like a memory hole for a dsp for direct-copy.