• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 419 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IPC ROV Display

npb17
Expert 1615 points

Hi,

I'm using CCS5 with the C6472 DSP and have a couple questions about the ROV display for IPC modules.

My application is setup similar to the message_multicore example in IPC 1.24.00.16, where a HeapBufMP is created dynamically within SharedRegion 0. I set the block size to 1500, but in ROV it shows 1536.  The cache line size and 'align' parameters are set to 64.  Is this constraining the HeapBufMP block size to be a multiple of 64?

In the SharedRegion ROV view, the reserved size is 1664 bytes.  How does this value get set?  And what is that memory reserved for?

Lastly, is there a way to check the number of free blocks for HeapBufMP instances from ROV?  I've been using Memory_getStats() from my application code. I can see the totalSize of the heap but the totalFreeSize is always 0 after getStats() returns.  I'd like to know about how much of the heap is being used for IPC so I can adjust the size accordingly.

Thanks,

Nick

  • 0
    TI__Mastermind 20805 points

    Hi Nick --

    [1]  If you have cache enabled for shared region 0, then HeapBufMP will internally round up the block size to be a multiple of the line size for the given cache region.  This is necessary since you typically don't want to have blocks of data on different cache lines.  Calling Cache_wb or invalidate on a block of data will do the operation on the full cache line, so you want to make sure you are not affecting some other data block.  

    [2] The reserved size of SR0 gets set internally by the IPC modules.   This area of memory is used for internal data structures used by IPC.

    [3] Try adding the following to your .cfg file to enable HeapBufMP to track the free list.   If you have this flag set to true, then HeapBufMP_alloc() will do some extra bookkeeping:

    var HeapBufMP = xdc.useModule('ti.sdo.ipc.heaps.HeapBufMP');
    HeapBufMP.trackAllocs = true;

    You can then use the extended stats API (HeapBufMP_getExtendedStats) to get additional information like maximum number of outstanding allocations for the given heap.  This is the high-water mark.

    Regards,
    -Karl-

     

  • 0 in reply to Karl Wechsler
    Expert 1615 points

    Thanks Karl.  I gave trackAllocs a try; it seems to keep a running total of all allocations and never decreases when memory is free'd.  For example, my HeapBufMP instance has 200 blocks available.  The total allocations stat passes above 200 (I watched it go to ~350 or more before an alloc() failed) while maxAllocations stops at 200.  Is this the expected behavior for these statistics?  If so, does my application have to keep track of the blocks that are returned to the heap?

  • 0 in reply to npb17
    Expert 1615 points

    Apparently the issue was that trackAllocs must be set to 'true' on all processors which utilize a HeapBufMP in shared memory.  Once I did that, the heap statistics were retrieved appropriately.