On Nov 16, 2007 12:52 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> > With appropriate interceptors added to hg_interceps.c, the picture is
> > different.
> > The test now fails due to missed timeouts (at least it looks so).
> > See attachment log2. We now see much more LSETs.
>
> Try increasing N_WAY_BITS from 16 to 17. That might improve performance
> a bit. Run on the fastest machine you have, with the largest L2 cache
> you can find (high end Core 2 machine?)
Well, this makes the program fail ~10% faster :)
>
>
> > How do I make sure that the test fails due to delayed timeouts and not
> due
> > to something else?
>
> I don't know. Make your application have longer timeouts?
>
> > Can I run helgrind so that it does all the intrusion (instrumentation),
> but
> > does *not* do any TSET/LSET/etc bookkeeping?
>
> No. What functionality should and should not be available in this
> "reduced functionality" mode?
I've commented out the body of hg_handle_client_request -- now everything
passes.
It's not very useful though. :) :)
I'll continue digging this...
>
>
> > Yet another question: can I include helgrind.h into my program as an
> > alternative to creating intercepts for my own locking primitives? Do you
> > have examples?
>
> No and no.
>
> J
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
