|
From: Brett C. <bc...@tu...> - 2004-09-10 04:33:52
|
Hi valgrind-developers, I've been using valgrind with memcheck to monitor the memory use of my PVM programs. Currently, spawning PVM children under valgrind requires recompiling my PVM code with a debug flag set on pvm_spawn calls. As one would imagine this can be annoying. I'd like to avoid having to recompile code and redistribute it around my cluster every time I wanted to use valgrind. It would be nicer to just be able to run valgrind in the usual manner, perhaps with new flags, such that the parent PVM task will automatically spawn the children as valgrind tasks. I was thinking that writing a skin would be the best way to do this, so I could intercept a pvm_spawn call and alter its arguments. Then I could specify which tool I'd want to use with valgrind on the children being spawned. There seem to be at least three approaches: 1. Develop a PVM skin, say pvmgrind, that can intercept pvm_spawns and spawn them under valgrind using a specified skin. For example: valgrind --tool=pvmgrind --tasktool=memcheck pvm_master <args> pvmgrind would then intercept a pvm_spawn call in pvm_master, spawning children like so: valgrind --tool=memcheck pvm_child <args> 2. PVMize an existing skin, such as memcheck, to pvmmemcheck say, and in this case pvm_spawns too would be intercepted and run under valgrind with the PVMized skin. For example: valgrind --tool=pvmmemcheck pvm_master <args> valgrind would then intercept a pvm_spawn call in any descendant task, including the pvm_master, and spawn the task like so: valgrind --tool=pvmmemcheck pvm_descendant <args> 3. PVMize valgrind itself. The problem with the first alternative is that PVM tasks spawned by a child PVM task do not get intercepted. So one would have to debug tasks according to their generation. The second has the problem that for each existing skin, one would have to produce a corresponding PVMized skin. The third is perhaps a gargantuan undertaking. Plus, this skin could be extended to monitor other PVM functions, like sends and receives etc. Hopefully the above makes sense, so if any one could answer the following I'd be grateful: 0) Which of these alternative seem the most plausible? 1) Does anything that valgrinds PVM already exist? My searches on the valgrind-developers and valgrind-users lists have yielded no results. 2) Would the method I explained be the best way to go about doing this, or am I way off track? 3) If so, how would I go about altering the function arguments? Thanks for your time. -- Brett Carson School of Mathematics, Statistics and Computer Science University of New England, Armidale, NSW 2351 Australia bc...@tu... Phone: +61 2 67732633 Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html Don't send me emails in HTML, HTML is for web pages. |
|
From: Tom H. <th...@cy...> - 2004-09-18 19:09:25
|
In message <167...@tu...>
Brett Carson <bc...@tu...> wrote:
> I've been using valgrind with memcheck to monitor the memory use of my
> PVM programs. Currently, spawning PVM children under valgrind requires
> recompiling my PVM code with a debug flag set on pvm_spawn calls. As
> one would imagine this can be annoying. I'd like to avoid having to
> recompile code and redistribute it around my cluster every time I
> wanted to use valgrind.
[ snip rest of mail ]
How about you tell us what PVM is before you go any further... Some
information about how pvm_spawn works and what this debug flag does
that makes it acceptable to valgrind and why it doesn't work without
that would always be useful.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bryan O'S. <bo...@se...> - 2004-09-19 23:03:50
|
On Sat, 2004-09-18 at 12:09, Tom Hughes wrote:
> How about you tell us what PVM is before you go any further...
It's the "parallel virtual machine", an implementation of an API for
writing parallel scientific applications using message passing. It was
popular over a decade ago; I wouldn't have guessed anyone even used it
any more (the most recent release notes say "ported to NT 3.51!"), much
less with valgrind.
It's long since been superseded by MPI ("message passing interface"),
which is a widely used standard for doing the same sort of thing.
<b
|