Bugzilla entry to follow up the prototype of improving the way Valgrind runs threads in parallel
Created attachment 71802 [details] document describing the prototype/problems/...
Created attachment 71803 [details] prototype patch (still *plenty* of problems) making core run threads in parallel !!!!! do not use for anything else than prototype evaluation. There are still *many* ugly things/thread non safe things/ulgy problems not looked at It only (maybe) compiles on x86 and amd64.
Created attachment 71804 [details] patch to implement tls (thread local storage) for Valgrind prototype on how tls variable (__thread attribute) variable could be supported in Valgrind
Is there a possibility to have the Valgrind mutli-core / multi-thread compatible with mipsel ? Cf "Bug 270777 - Adding MIPS/Linux port to Valgrind " Best Regards,
(In reply to comment #4) > Is there a possibility to have the Valgrind mutli-core / multi-thread > compatible with mipsel ? At this stage, this bug entry is just a place holder for ideas/discussions and very partial prototype which is buggy/non fully thread safe/... This is not at all usable for any work, for many reasons. But if this results one day in something usable, I do not see why it would not be possible for mips to use it : most of the difficulty is in the core of Valgrind and the tools themselves, not in the arch cpu specific code.
The case of internal counters for statistics or performance monitoring is simple to fix. Change any such counter into a thread-local variable, and add a function which sums the values across all threads. In many cases the function does not need a big lock, nor exclusive access. The counters are monotonic, and a sum which may be low by a few counts (a few per thread) usually is just fine.
For the specific tool memcheck, it seems that significant pieces of the tool-specific data structures are "monotonic": they only grow, and do not shrink; or the values change only in one direction, at least for relatively long (and demarcated) periods of time, such as from 'malloc' to 'free'. Exploiting such monotonicity might be helpful.
(In reply to comment #6) > The case of internal counters for statistics or performance monitoring is > simple to fix. Change any such counter into a thread-local variable, and > add a function which sums the values across all threads. In many cases the > function does not need a big lock, nor exclusive access. The counters are > monotonic, and a sum which may be low by a few counts (a few per thread) > usually is just fine. I did a trial to use thread local storage (see attachment 3 [details]) Not trivial to use as Valgrind cannot use any libc support. So, it was needed to emulate a part of the needed run-time support expected by the compiler. This proto was working on some platforms (x86/amd64/ppc IIRC. arm looked more tricky. not looked as s390). But the main problem (the V bits data structure) cannot be solved by TLS.
Created attachment 77718 [details] patch updated to recent svn version + modified perf tests + doc Documentation has been added in docs/internals/mtV.txt gdbserver_tests/sleepers now accepts an additional arg 5 -p to make it run on more than 1 CPU perf/big_parallel_sleepers is burning cpu with bigger code (to shake the translation logic/tables)
(In reply to comment #9) > Created attachment 77718 [details] > patch updated to recent svn version + modified perf tests + doc Committed as r13341, on branches/MTV. To checkout: svn co svn://svn.valgrind.org/valgrind/branches/MTV MTV cd MTV
Created attachment 80023 [details] patch for mips
Hi In attachment the "patch for mips" : Addons to compile on mipsel At the launch , it crashes , it seems to be caused by the delta between this branch and the main. Regards, Frédéric Something called raise(). valgrind: m_main.c:2678 (abort): the 'impossible' happened. ==2063== at 0x38034990: report_and_quit (m_libcassert.c:264) ==2063== by 0x38034B44: vgPlain_assert_fail (m_libcassert.c:344) ==2063== by 0x3803FEE4: abort (m_main.c:2678) ==2063== by 0x380828DC: vgPlain_scheduler (scheduler.c:1349) ==2063== by 0x38096020: run_a_thread_NORETURN (syswrap-linux.c:103) ==2063== by 0x38096408: vgPlain_main_thread_wrapper_NORETURN (syswrap-linux.c:396) sched status: Thread 1: status = VgTs_Runnable slk = VgTs_ReadLock in_gen_code 0 ==2063== at 0x4000ED0: _start (in /lib/ld-uClibc-0.9.33.2.so) ==2063== by 0x7EF7CBD8: ???