Re: .eh_frame, .eh_frame_hdr - how to remove that trash
on entry into each function, which is different from usual x86 convention. Asynchronous unwind info (yeah, same stuff you keep referring to as crap), is the only way you can debug your program or get anything remotely close to usable backtrace, by default. i understand but i DO NOT called compiler with -g option which clearly means that i do not want to debug isn't it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: .eh_frame, .eh_frame_hdr - how to remove that trash
On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar wrote: >> on entry into each function, which is different from usual x86 >> convention. >> Asynchronous unwind info (yeah, same stuff you keep referring to as >> crap), is the only way you can debug your program or get anything >> remotely close to usable backtrace, by default. > > i understand but i DO NOT called compiler with -g option which clearly means > that i do not want to debug isn't it? It seems like a binutils bug (or somewhere in that immediate neighborhood) because all debugging related sections should be stripped out by strip including unwind, correct? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
Le 20.10.2011 19:57, Razmig K a écrit : the memory footprint in C/C++ code for a program running under FreeBSD and Linux in terms of total process size including heap objects Well getrusage does actually exist in Linux, but its behaviour isn't the same as on FreeBSD; struct rusage memory usage information fields ru_ixrss (shared text), ru_idrss (unshared data) and ru_isrss (unshared stack) are always zero. To test and understand the behaviour of getrusage on FreeBSD, I have written a small C++ program that allocates several large double arrays on the stack as well as on the heap with few loops to delay execution, and tried using the aforementioned fields, in addition to ru_maxrss (max resident size) to deduce memory usage information of the program as reported by top, namely fields RES and SIZE, but somehow I didn't manage to get a result matching that of the latter. First of all, I'm not sure if I interpret man getrusage correctly. For ru_ixrss, it says that it is an "integral" value indicating the amount of memory used by the text segment that was also shared among other processes, and is expressed in units of kilobytes * ticks-of-execution, where ticks are statistics clock ticks, the statistics clock having a frequency of sysconf(_SC_CLK_TCK) ticks per second. Does this imply that I need to divide ru_ixrss by sysconf(_SC_CLK_TCK) * a certain number of seconds? In that case, what do I use for the latter? ru_stime or ru_utime? I have observed that unlike ru_idrss, ru_ixrss and ru_isrss depend on execution time which contradicts the manpage, since all three fields are supposed to be specified in the same unit. Lastly, I don't see how to use getrusage to deduce information on the program's heap use. As I said in my first message, I need to measure the memory footprint in terms of total process size including heap objects. Thanks again for any tips. ~Razmig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: .eh_frame, .eh_frame_hdr - how to remove that trash
that i do not want to debug isn't it? It seems like a binutils bug (or somewhere in that immediate neighborhood) because all debugging related sections should be stripped out by strip including unwind, correct? indeed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
Le 21.10.2011 10:44, Peter Jeremy a écrit : On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: It's not clear whether the program is attempting to determine it's own (or a child's) memory footprint, or that of an arbitrary process. In the former case, getrusage() is the obvious choice. This as a portable interface. The program has to determine its own memory footprint. It has no children. If you want to examine arbitrary processes, the best interface on FreeBSD would be kvm_getprocs(3). BTW, since you mention heap objects, I presume you are aware that malloc() uses mmap(), rather than sbrk() to obtain memory. No I wasn't aware of that. In few words, the program needs to obtain and report information reported by the SIZE column of top, since it is going to be run many times, and it is impractical to watch top for this purpose. Thanks. ~Razmig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
On 21/10/2011 12:19, Razmig K wrote: > Le 21.10.2011 10:44, Peter Jeremy a écrit : >> On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: >> It's not clear whether the program is attempting to determine it's >> own (or a child's) memory footprint, or that of an arbitrary process. >> In the former case, getrusage() is the obvious choice. This as a >> portable interface. > The program has to determine its own memory footprint. It has no children. > >> >> If you want to examine arbitrary processes, the best interface on >> FreeBSD would be kvm_getprocs(3). >> >> BTW, since you mention heap objects, I presume you are aware that >> malloc() uses mmap(), rather than sbrk() to obtain memory. > No I wasn't aware of that. > > In few words, the program needs to obtain and report information > reported by the SIZE column of top, since it is going to be run many > times, and it is impractical to watch top for this purpose. Well, do you know that SIZE in top is virtual memory size, not resident size (which is the "RES" column)? You can allocate whatever you want from virtual memory, it is not "used" until it's touched. signature.asc Description: OpenPGP digital signature
Re: Measuring memory footprint in C/C++ code on FreeBSD
Le 21.10.2011 12:26, Ivan Voras a écrit : Well, do you know that SIZE in top is virtual memory size, not resident size (which is the "RES" column)? You can allocate whatever you want from virtual memory, it is not "used" until it's touched. Yes, I do. So do you suggest using RES as a better indicator of memory footprint? The program in question processes large 3D images via vtk, and I'd like to measure its memory usgae with different parameter configurations as the maximum amount of memory acquired during execution. Since SIZE often happens to be larger than RES, and increase more during execution, I thought of using it as an indicator of memory footprint. ~Razmig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: > I'd like to measure the memory footprint in C/C++ code for a >program running under FreeBSD and Linux in terms of total process size >including heap objects. Due to execution length, I'd like to avoid the >use of valgrind. It's not clear whether the program is attempting to determine it's own (or a child's) memory footprint, or that of an arbitrary process. In the former case, getrusage() is the obvious choice. This as a portable interface. If you want to examine arbitrary processes, the best interface on FreeBSD would be kvm_getprocs(3). BTW, since you mention heap objects, I presume you are aware that malloc() uses mmap(), rather than sbrk() to obtain memory. -- Peter Jeremy pgphug33XKVIW.pgp Description: PGP signature
Re: Measuring memory footprint in C/C++ code on FreeBSD
On 21/10/2011 12:57, Razmig K wrote: > Le 21.10.2011 12:26, Ivan Voras a écrit : >> Well, do you know that SIZE in top is virtual memory size, not resident >> size (which is the "RES" column)? You can allocate whatever you want >> from virtual memory, it is not "used" until it's touched. > > Yes, I do. So do you suggest using RES as a better indicator of memory > footprint? Almost certainly yes. Measuring virtual memory is significantly less important for real-world loads. Some of this is very nicely described here: https://www.varnish-cache.org/trac/wiki/ArchitectNotes . > The program in question processes large 3D images via vtk, and I'd like > to measure its memory usgae with different parameter configurations as > the maximum amount of memory acquired during execution. Since SIZE often > happens to be larger than RES, and increase more during execution, I > thought of using it as an indicator of memory footprint. No; the difference between SIZE and RES is "slack space" - allocated but untouched virtual memory, which is *NOT PRESENT IN RAM*. You can verify this yourself: make a small C program and allocate twice the physical memory (+swap) you have on the machine (try terabytes on a 64-bit machine), and it will succeed. If you look at this program in top, it should (barring some optimizations) show you that SIZE is huge, but RES is a couple of MB, basically like you didn't allocate anything at all. Now, it is a whole other thing if you try to actually *use* this memory you've allocated. Here's a random link on the topic from Google: http://opsmonkey.blogspot.com/2007/01/linux-memory-overcommit.html . Unfortunately, the phrase "memory overcommit" has been hijacked by the virtualization environment to mean the same thing but relating to the memory in virtual machines. signature.asc Description: OpenPGP digital signature
Re: Measuring memory footprint in C/C++ code on FreeBSD
footprint?
Almost certainly yes. Measuring virtual memory is significantly less
important for real-world loads. Some of this is very nicely described
here: https://www.varnish-cache.org/trac/wiki/ArchitectNotes .
definitely.
just run top and compare RES and SIZE fields.
extreme example:
#include
int blah[10];
main(){sleep(1000);}
run it and see this in top
13317 wojtek1 450 3817M 684K nanslp 0 0:00 0.00% 1
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
In the last episode (Oct 21), Razmig K said: > Le 21.10.2011 10:44, Peter Jeremy a écrit : > > On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: > > It's not clear whether the program is attempting to determine it's own > > (or a child's) memory footprint, or that of an arbitrary process. In > > the former case, getrusage() is the obvious choice. This as a portable > > interface. > > The program has to determine its own memory footprint. It has no children. > > > If you want to examine arbitrary processes, the best interface on > > FreeBSD would be kvm_getprocs(3). > > > > BTW, since you mention heap objects, I presume you are aware that > > malloc() uses mmap(), rather than sbrk() to obtain memory. > > No I wasn't aware of that. > > In few words, the program needs to obtain and report information > reported by the SIZE column of top, since it is going to be run many > times, and it is impractical to watch top for this purpose. top also uses kvm_getprocs, so you can use that as a template (see the manpage and source at usr/src/usr.bin/top/machine.c). If you call it with the KERN_PROC_PID flag, you can get the stats for a single processs by pid. If you want even more detail, you can look at the source to the procstat command, which uses some other calls to dump the vm map of processes. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: .eh_frame, .eh_frame_hdr - how to remove that trash
On Fri, 21 Oct 2011 00:54:32 -0700 Garrett Cooper wrote: > On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar > wrote: > >> on entry into each function, which is different from usual x86 > >> convention. > >> Asynchronous unwind info (yeah, same stuff you keep referring to as > >> crap), is the only way you can debug your program or get anything > >> remotely close to usable backtrace, by default. > > > > i understand but i DO NOT called compiler with -g option which > > clearly means that i do not want to debug isn't it? > > It seems like a binutils bug (or somewhere in that immediate > neighborhood) because all debugging related sections should be > stripped out by strip including unwind, correct? > Thanks, > -Garrett NO. Unwind info is a part of the ABI, and its relationship to debug flags as well as to wishes of the OP is very remote. -- Alexander Kabaev signature.asc Description: PGP signature
