I have a question about the .map file generated in IAR embedded workbench.
I'm working with MK60DN512VLQ10 that have 512 KB of flash memory and 128 KB RAM.
Which of the below is stored in Flash and which on RAM?
158 852 bytes of readonly code memory
18 446 bytes of readonly data memory
22 532 bytes of readwrite data memory
This is the total memory usage or it changes in run time?
Thanks.
It depends somewhat on your linker configuration but given a normal linker configuration the readonly memory is placed in flash and the readwrite memory is placed in RAM. The answer to the second question also depends on the linker configuration but under typical conditions the readwrite number includes both the block containing the c stack and the block reserved for the heap.
Related
We have an 64-bit application that runs in c++ code in 16gb ram windows virtual machine. After few days of running the application,whole Pagefile.sys memory(32 GB) got filed and leads to crash.In resource monitor
Commit(KB): 22 643 396
Working Set (KB): 982 208
If it is memory leak why it doesn't showing growth in Working set memory ? I would also like to know in what situations, only commit memory will grow greater than working set memory? What tools for c++ we can use to identify the root cause for this problem?
I understand that commit size includes RAM used and Virtual memory. please explain why virtual memory used not able to deallocate even process in idle state?
Note:-In this application no virtualAlloc() has used only c++ new operator has been used.
If I query the maximum compute shader shared memory size with:
GLint maximum_shared_mem_size;
glGetIntegerv(GL_MAX_COMPUTE_SHARED_MEMORY_SIZE, &maximum_shared_mem_size);
I get 48KB as a result. However, according to this whitepaper:
https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf
on page 13, it is stated, that for my GPU (2080TI):
The Turing L1 can be as large as 64 KB in size, combined with a 32 KB per SM shared memory allocation, or it can reduce to 32 KB, allowing 64 KB of allocation to be used for shared memory. Turing’s L2 cache capacity has also been increased.
So, I expect OpenGL to return 64KB for the maximum shared memory size.
Is this a wrong assumption? If so, why?
It looks like the 48KB is the expected result, as documented in the Turing Tuning Guide for CUDA:
Turing allows a single thread block to address the full 64 KB of shared memory. To maintain architectural compatibility, static shared memory allocations remain limited to 48 KB, and an explicit opt-in is also required to enable dynamic allocations above this limit. See the CUDA C Programming Guide for details.
It seems that you can either take the default 48KB or use CUDA to gain control over the carveout configuration.
I have a C++ app which generates raw bitmap images in runtime and pushes those into temporary std::vector allocating the memory dynamically on each write, which is then used to write those images to file before the program exists.Currently the bitmap size is 1280x720. I am getting "bad allocation" error after frame 650 +- 3 frames.It is pretty clear to me that the reasons for this is not enough RAM memory.That is because if I make smaller size (let'say 300x200) I manage to store all the 950 frames ok.It is strange because my machine has 16gb of RAM.Also in the task manager I see the RAM display has still a lot of free (dark green) space(getting only 5gb in use at most).It utilize like 1/3 of the space only.I am running on Windows 7 64bit 16gb RAM Intel I7 CPU.I am debugging the program in VS2012.Is it possible the OS restricts the dynamic allocation to some arbitrary size?If yes, how can I lift that restriction?
The type of data is bytes (unsigned chars).And yes ,as someone mentioned in the answer below , I compile for 32bit.
1280 x 720 x 3 (bytes/pixel) = 2764800 bytes/image = 2.64 MB/image (I'm supposing 24 bpp images here)
2.64 MB/image x 650 images = 1713.87 MB, really near to the dreaded 2 GB boundary. This makes me thing that you are running on a 64 bit OS, but your application is compiled as a 32 bit application without the /LARGEADDRESSAWARE linker flag, thus it has only a 2 GB virtual address space available1.
To easily exploit the physical RAM available on your machine you can compile your program as a 64 bit application (thus rendering substantially irrelevant the virtual address space limitations). Other methods are quite a bit more complicated (usually they involve managing "sliding windows" of memory by yourselves).
Another option is to compile your application with the /LARGEADDRESSAWARE linker flag, but you are going to actually get more memory on 32 bit systems launched with the /3GB kernel option or on 64 bit systems (respectively, 1 GB more and 2 GB more); also, given that the high bit of the addresses can be set, then you have to be careful in what you do with pointers (subtraction and comparisons can be tricky).
Actually, 32 bit pointers can address a full 4 GB virtual address space, but the upper half is reserved for the system by default.
I write my project by c with opencv.
I want print info about allocated memory or memory used by my program.
Is there a functions, that give me the information about the memory ?
Finally I'm using Qt for Linux and Windows ,
Thanks in advance.
On Linux you look into your own process info pseudo-file:
/proc/[pid]/statm
Provides information about memory usage, measured in pages. The columns are:
size total program size
(same as VmSize in /proc/[pid]/status)
resident resident set size
(same as VmRSS in /proc/[pid]/status)
share shared pages (from shared mappings)
text text (code)
lib library (unused in Linux 2.6)
data data + stack
dt dirty pages (unused in Linux 2.6)
On Windows you look at you own process Process Object performance counters:
Private Bytes Shows the current number of bytes that this process has allocated that cannot be shared with other processes.
You can write wrappers to malloc and free that track how much memory you're using.
EDIT: If you also want to intercept calls to malloc and free in external libraries, you will have to define them in a shared library and load it before libc. How you do this depends on your OS.
You can also do some level of memory analysis of Code/Data segment during build time if you check elf, dump or map file.
And GCC command line options for stack usage are: -fstack-usage and -fcallgraph-info.
I'm writing an application in C++ which uses some external open source libraries. I tried to look at the Ubuntu System Monitor to have information about how my process uses resources, and I noticed that resident memory continues to increase to very large values (over 100MiB). This application should run in an embedded device, so I have to be careful.
I started to think there should be a (some) memory leak(s), so I'm using valgrind. Unfortunately it seems valgrind is not reporting significant memory leaks, only some minor issues in the libraries I'm using, nothing more.
So, do I have to conclude that my algorithm really uses that much memory? It seems very strange to me... Or maybe I'm misunderstanding the meaning of the columns of the System Monitor? Can someone clarify the meaning of "Virtual Memory", "Resident Memory", "Writable Memory" and "Memory" in the System Monitor when related to software profiling? Should I expect those values to immediately represent how much memory my process is taking in RAM?
In the past I've used tools that were able to tell me where I was using memory, like Apple Profiling Tools. Is there anything similar I can use in Linux as well?
Thanks!
Another tool you can try is the /lib/libmemusage.so library:
$ LD_PRELOAD=/lib/libmemusage.so vim
Memory usage summary: heap total: 4643025, heap peak: 997580, stack peak: 26160
total calls total memory failed calls
malloc| 42346 4528378 0
realloc| 52 7988 0 (nomove:26, dec:0, free:0)
calloc| 34 106659 0
free| 28622 3720100
Histogram for block sizes:
0-15 14226 33% ==================================================
16-31 8618 20% ==============================
32-47 1433 3% =====
48-63 4174 9% ==============
64-79 4736 11% ================
80-95 313 <1% =
...
(I quit vim immediately after startup.)
Maybe the histogram of block sizes will give you enough information to tell where leaks may be happening.
valgrind is very configurable; --leak-check=full --show-reachable=yes might be a good starting point, if you haven't tried it yet.
"Virtual Memory", "Resident Memory", "Writable Memory" and "Memory"
Virtual memory is the address space that your application has allocated. If you run malloc(1024*1024*100);, the malloc(3) library function will request 100 megabytes of storage from the operating system (or handle it out of the free lists). The 100 megabytes will be allocated with mmap(..., MAP_ANONYMOUS), which won't actually allocate any memory. (See the rant at the end of the malloc(3) page for details.) The OS will provide memory the first time each page is written.
Virtual memory accounts for all the libraries and executable objects that are mapped into your process, as well as your stack space.
Resident memory is the amount of memory that is actually in RAM. You might link against the entire 1.5 megabyte C library, but only use the 100k (wild guess) of the library required to support the Standard IO interface. The rest of the library will be demand paged in from disk when it is needed. Or, if your system is under memory pressure and some less-recently-used data is paged out to swap, it will no longer count against Resident memory.
Writable memory is the amount of address space that your process has allocated with write privileges. (Check the output of pmap(1) command: pmap $$ for the shell, for example, to see which pages are mapped to which files, anonymous space, the stack, and the privileges on those pages.) This is a reasonable indication of how much swap space the program might require in a worst-case swapping scenario, when everything must be paged to disk, or how much memory the process is using for itself.
Because there are probably 50--100 processes on your system at a time, and almost all of them are linked against the standard C library, all the processes get to share the read-only memory mappings for the library. (They also get to share all the copy-on-write private writable mappings for any files opened with mmap(..., MAP_PRIVATE|PROT_WRITE), until the process writes to the memory.) The top(1) tool will report the amount of memory that can be shared among processes in the SHR column. (Note that the memory might not be shared, but some of it (libc) definitely is shared.)
Memory is very vague. I don't know what it means.