|
From: Brian B. <bri...@gm...> - 2013-04-17 22:49:56
|
Hi all - I've been using valgrind for a long time. I just upgraded to 3.81, and I see my %CPU in top at close to 1000. I think I've only ever seen 100 or less before. One difference is that this time I used --enable-tls. Does this actually allow threads to work concurrently? Thanks, Brian |
|
From: <pa...@fr...> - 2013-04-18 12:28:39
|
----- Original Message ----- > Hi all - > > I've been using valgrind for a long time. I just upgraded to 3.81, > and I see my %CPU in top at close to 1000. I think I've only ever > seen 100 or less before. One difference is that this time I used > --enable-tls. Does this actually allow threads to work concurrently? Hi Usually when I see excessive loads like that, the cause is swapping rather than a normal user load. Are you well within your RAM+swap limits? A+ Paul |
|
From: Brian B. <bri...@gm...> - 2013-04-18 15:50:44
|
Hi Paul. I am at <20% of memory use. I should also note that I followed Julian's advice for increasing vg_n_segments and memory size to 128 GB. Does valgrind itself do anything multithreaded? My program uses all cores on the machine at various stages of the program running. But my understanding was that it was always serialized while running memcheck. Thanks. Brian On Apr 18, 2013 5:31 AM, <pa...@fr...> wrote: > > ----- Original Message ----- > > Hi all - > > > > I've been using valgrind for a long time. I just upgraded to 3.81, > > and I see my %CPU in top at close to 1000. I think I've only ever > > seen 100 or less before. One difference is that this time I used > > --enable-tls. Does this actually allow threads to work concurrently? > > Hi > > Usually when I see excessive loads like that, the cause is swapping rather > than a normal user load. Are you well within your RAM+swap limits? > > A+ > Paul > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Philippe W. <phi...@sk...> - 2013-04-23 20:04:17
|
On Thu, 2013-04-18 at 08:50 -0700, Brian Budge wrote: > Hi Paul. I am at <20% of memory use. I should also note that I > followed Julian's advice for increasing vg_n_segments and memory size > to 128 GB. > > Does valgrind itself do anything multithreaded? My program uses all > cores on the machine at various stages of the program running. But my > understanding was that it was always serialized while running > memcheck. In fact, any tool is (almost fully) serialising the execution: there is only one thread that can "execute" code. the only parallelism is with the threads that are executing a system call. Some prototyping was done of a non serialised valgrind. See https://bugs.kde.org/show_bug.cgi?id=301830 and the MTV branch in svn. This prototype is not usable in its current state: only the none tool was used. There are still many thread unsafe things. The performance of the memcheck data structures is a.o. a difficult problem to look at. Philippe |
|
From: Brian B. <bri...@gm...> - 2013-04-23 20:08:28
|
On Tue, Apr 23, 2013 at 1:04 PM, Philippe Waroquiers < phi...@sk...> wrote: > > Some prototyping was done of a non serialised valgrind. > See https://bugs.kde.org/show_bug.cgi?id=301830 > and the MTV branch in svn. > This prototype is not usable in its current state: only the > none tool was used. There are still many thread unsafe things. > The performance of the memcheck data structures is a.o. a difficult > problem to look at. > > Philippe > > > Hi Philippe - I can definitely understand that :) I wasn't really suggesting that it should do so (though, of course, any performance improvement would be great). I was more just confused that memcheck was using so many cores concurrently. Brian |
|
From: Philippe W. <phi...@sk...> - 2013-04-23 20:11:43
|
On Tue, 2013-04-23 at 13:08 -0700, Brian Budge wrote: > Some prototyping was done of a non serialised valgrind. > See https://bugs.kde.org/show_bug.cgi?id=301830 > and the MTV branch in svn. > This prototype is not usable in its current state: only the > none tool was used. There are still many thread unsafe things. > The performance of the memcheck data structures is a.o. a > difficult > problem to look at. > > Philippe > > > Hi Philippe - > > > I can definitely understand that :) I wasn't really suggesting that > it should do so (though, of course, any performance improvement would > be great). I was more just confused that memcheck was using so many > cores concurrently. Yes, it is not very understandable, unless you have a lot of threads, with many of them executing (heavy) system calls. (but I am still amazed that you could obtain something like 1000% of cpu). Philippe |