In .ini file, we can set TOTAL_ROW_ACCESSES to control the scheduling by enforcing a cap on total row accesses to a row in open page policy.
But in some cases the actual number of accesses will exceed this assigned number by 1. Here is how it happens:
In CommandQueue.cpp, let's say in line 419, an ACTIVATE is first time issued to a bank and followed by its CAS (READ/WRITE) commands. This CAS command won't increment the rowAccessCounters in line 444 because by the time it gets here the ACTIVATE was gone.
So as a result there could be at most TOTAL_ROW_ACCESSES+1 CAS commands to the same row instead of TOTAL_ROW_ACCESSES.
Again, this is not timing violation or something wrong. But could be confusing.
In .ini file, we can set TOTAL_ROW_ACCESSES to control the scheduling by enforcing a cap on total row accesses to a row in open page policy.
But in some cases the actual number of accesses will exceed this assigned number by 1. Here is how it happens:
In CommandQueue.cpp, let's say in line 419, an ACTIVATE is first time issued to a bank and followed by its CAS (READ/WRITE) commands. This CAS command won't increment the rowAccessCounters in line 444 because by the time it gets here the ACTIVATE was gone.
So as a result there could be at most TOTAL_ROW_ACCESSES+1 CAS commands to the same row instead of TOTAL_ROW_ACCESSES.
Again, this is not timing violation or something wrong. But could be confusing.