|
From: Konstantin S. <kon...@gm...> - 2009-10-26 09:20:31
|
On Wed, Oct 21, 2009 at 1:54 AM, Julian Seward <js...@ac...> wrote: > On Wednesday 14 October 2009, Konstantin Serebryany wrote: > > On Wed, Oct 14, 2009 at 4:05 PM, Julian Seward <js...@ac...> wrote: > > > On Wednesday 14 October 2009, Konstantin Serebryany wrote: > > > > > I did not think about opening this file for the duration of the > > > > > run... > > > : > > > :) > > > : > > > > > I need to check the occupied memory very often so that the tool can > > > > > > ^^^^^^^^^^ > > > > > > Actually, you only need to check it when the process' mappings change, > > > or when sbrk happens, since that's the only way(s) the process can > > > acquire more memory. No need for spin-style polling. > > > > > > So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap" > > > > This will notify me when the client program does mmap/brk. Right? > > Yes. > > > But I also need to watch for mmap/brk of valgrind itself. Is it possible? > > Hmm, good point. I didn't think of that. Not sure that's easily possible. > How about this Plan B: Get the scheduler to notify you of start/stop > of running of client code (probably you already do): > > void VG_(track_start_client_code)( > void(*f)(ThreadId tid, ULong blocks_dispatched) > ); > void VG_(track_stop_client_code)( > void(*f)(ThreadId tid, ULong blocks_dispatched) > ); > > and look at 'blocks_dispatched'. Whenever that changes by (eg) > more than one million, re-read /proc/self/whatever etc. > Maybe... But that's not any different from what I do know (read /proc/self every N-th event of some kind). --kcc > > J > |