You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: