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.

OMX_Init memory problem

Hi,

I am using EZSDK 5.02.02.60,  and we are using openMax for capture frame from cameras.

I found that about 248M(top %mem column) memory will be used after called OMX_Init() funtion. 

In our program, we just used the VFCC component of OpenMax,

so can I config it (e.g.  just init the VFCC part) to malloc memories which are really necessary for capture?

Regards,

lei

  • Hi,

    I believe OMX_Init() immediately mmap()s all of the various shared regions which are visible from the host.  From http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map , this includes the region IPC_SR_FRAME_BUFFERS which is 188MB and makes up most of the memory you can see.

    The memory which it maps in this way is not normal Linux memory, so very little of your 248MB will be counting against other programs running in Linux only (have a look at the Linux memory still available with "free").  If you really want to reduce that number then you'll need to modify the memory map to make IPC_SR_FRAME_BUFFERS smaller (and possibly some of the other regions it maps, but that's by far the largest one).

    - Mark

  • Hi Mark,

    This is the top message when I run my capture program.

    Mem: 43064K used, 270132K free, 0K shrd, 2548K buff, 20968K cached
    CPU: 32% usr 0% sys 0% nic 67% idle 0% io 0% irq 0% sirq
    Load average: 0.06 0.31 0.18 2/63 1128
    PID PPID USER STAT VSZ %MEM %CPU COMMAND
    1119 1097 root S 248m 81% 33% ./VportCommTest
    22 2 root SW 0 0% 0% [kworker/0:1]
    1104 1102 root R 3128 1% 0% top
    1097 1096 root S 3128 1% 0% -sh

    It shows that my program has used 248m.  (including virtual memory which means the 188M share region?)

    And the value of MEM% column if 81%. what does the percentage mean? 

    Regards,

    lei

  • Hi Lei,

    The MEM% column is just naïvely dividing the virtual size of the process by what top thinks is the total memory size of the machine (that is, the total amount of memory managed by Linux), which is pretty much meaningless when other memory (not managed by Linux) can be mapped in.  You can easily get this column to show more than 100% without it being a problem.

    The "43064K used" in the summary line is actually reflecting how much Linux memory is in use (in that case by the kernel and all processes) - your program is certainly using quite a bit less than the 43MB of that.

    - Mark

  • OMX buffers are alloacted from SR2. If you use latest EZSDK, you can run sys_top utility to see the memory usage by omx components.

    Regards

    Vimal