POV-Ray : Newsgroups : povray.off-topic : One thing which puzzles me about unix/linux : Re: One thing which puzzles me about unix/linux Server Time
1 Oct 2024 09:21:32 EDT (-0400)
  Re: One thing which puzzles me about unix/linux  
From: Warp
Date: 5 Apr 2008 17:30:19
Message: <47f7fd7b@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> If saying "hey, I just called sbrk() for another page of memory" or "I 
> just did six I/Os to satisfy a select query" was as easy as sending 
> something to syslog, I expect a lot more libraries would implement those 
> sorts of measurements.

  I'm not exactly sure what you mean by that. Examining the brk() system
calls made by a process is quite easy using 'strace' (or in some unix systems
'truss').

  Examining brk() calls can actually be used to get a pretty accurate figure
of the memory usage of the program, but it's not always that unambiguous.
Basically you would need to know what is the base address used by the
program so that you can substract the largest value of brt() from that.
Usually the first brk() request made by the process is a good bet, but
the result may still be a bit biased. Another way is to put some debug
print at the beginning of main() and start counting brk() calls from
there, which gives the amount of memory allocated by the program after
its main() has started. (This can be done easily in the program itself
by making an sbrk(0) call at the beginning of main() and another at the
end and calculating their difference, which will give the amount of memory
in bytes that the program has allocated.)

  OTOH, only examining brk() calls is not the whole story and doesn't
always give the real amount of memory allocated by the program. This is
because libc sometimes makes cleverl tricks using mmap2() to allocate
memory, bypassing brk(). Thus any memory allocated that way will be
missed if we examine only brk().

  But anyways, for my purposes it would be enough to get whatever tools
like 'top' are using to measure the memory usage of the program.

> Say, did you try things like Purify? Shouldn't that be able to track it, 
> since it replaces malloc and free?

  Simply examining mallocs and frees performed by the program does not
give an accurate figure. The actual amount of memory used by the program
may be significantly larger. For example memory fragmentation can cause
this quite prominently.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.