|
From: Carl E. L. <ce...@li...> - 2013-06-28 16:14:08
|
Julian:
I am starting to look at how to implement the new Power ISA 2.07
Transactional memory instructions.
The discussion thread talked about trying to do your suggestion 1) of
pushing the simulated execution directly onto the failure path as a
simple first attempt. I am wondering how I would go about doing that so
I can try implementing support for the transaction begin and end
instructions. Not sure how this will work for the PPC suspend and
resume instructions. Not sure that we will be able to goto a failure
path, stop this path and then come back to it later. But I figure I
need to get started somewhere to really start understanding how this
would work or not work in Valgrind for the power instructions. Anyway,
any input on the specifics of how I push the simulated execution
directly to the failure path would be helpful. Thanks.
Carl Love
Date: Thu, 20 Jun 2013 15:39:42 +0200
From: Julian Seward <js...@ac...>
Subject: Re: [Valgrind-developers] Transactional Memory support
To: Josef Weidendorfer <Jos...@gm...>
Cc: Valgrind Dev Maillist <val...@li...>
Message-ID: <51C...@ac...>
Content-Type: text/plain; charset=ISO-8859-1
On 06/20/2013 02:15 PM, Josef Weidendorfer wrote:
> But the code added by VG +
> tool (just assume cache simulation) will raise the probability for
> transaction failure significantly.
Yes .. I agree with that.
> And doing a rollback + failure path
> is slower than doing the failure path from the beginning. So (1) may
> not be a bad option at all.
OK, worth a try. At least it gives us an ultra-simple baseline
implementation. I expect to have a Haswell box to try with, soon.
That's Intel-specific, though. The question of whether we can fit
Power/s390 into the same framework is also important.
> What about
> (3) if XBEGIN/XEND is found in the same SB, remove them. As VG is
> serializing threads, there is no way for a conflict within a SB
anyway.
OK for now, but if we continue Philippe Waroquiers' work on
multithreaded
Valgrind, then that serialization might go away one day.
> PS: Using TM ourself should be a very nice solution to make memcheck
> fast when we remove serializing of threads at one point. The move
> forward here would be to let the tool decide whether VG core should
> do serialization or not. If TM is not available, memcheck would
> go with thread serialization as now.
Hmm, interesting.
Some time earlier this year I worked out most of the details for making
memcheck multithreaded without using TM, and posted the details to the
list
(I think). Philippe points out though that we will in any case need to
retain the ability to serialize so as not to force tool authors to
completely rewrite tools for multithreaded operation.
J
|