I added some counters to undoTx implementation to track the number of fences & flushes issued, and the numbers seem too many. This is some of the data:
# of elements logged
# of Fences issued
# of Flushes issued
0
4
2
1
7
7
2
9
11
3
11
15
These are some of my observations:
The setup cost is too high. In particular, for no elements being logged, 4 fences & 2 flushes are too many.
As the number of elements logged increase, we issue 4 additional flushes & 2 additional fences. This seems reasonable.
We can start by optimizing for some common cases, for example when transaction ended successfully, there is no need to do any work when releaseundoTx() is called.
I added some counters to undoTx implementation to track the number of fences & flushes issued, and the numbers seem too many. This is some of the data:
These are some of my observations:
We can start by optimizing for some common cases, for example when transaction ended successfully, there is no need to do any work when releaseundoTx() is called.