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