configs/ruby/MOESI_hammer.py (Diff revision 1)

All of this probe filter setup should be predicated on whether the probe filter is actually enabled (options.pf_on = True). If the probe filter is NOT enabled, then it should be possible to set options.numa_high_bit within the pf_bits range (not currently possible because of this assertion). Trying to fix up the pf_start_bit without first checking whether the probe filter is enabled will probably cause redundant changes down the road.

Is anyone actually using the probe filter?

Show all issues

1. Brad Beckmann Sept. 12, 2012, 1:56 a.m. (Sept. 12, 2012, 1:56 a.m.)

   I still use it and I suspect others find it useful as well.  Sure we can wrap the current set of computation under the assumption of whether the probe filter or full-bit directoy is enabled.

2. Joel Hestness Sept. 12, 2012, 4:58 a.m. (Sept. 12, 2012, 4:58 a.m.)

   Cool. Thanks for the head's up. I've incorporated this into our updated patch which we'll resubmit for review.
   
   I'm also a bit confused about the default setting of numa_high_bit when the probe filter or full-bit directory is enabled. If you don't explicitly set numa_high_bit, it will default to one of the bits just above the block offset (depending on number of directories), which according to this assertion, should fail. Simulation seems to complete correctly with pf_on or dir_on, and the default numa_high_bit. Is that appropriate desired functionality?

configs/ruby/Ruby.py (Diff revision 1)

Is this distinction necessary? When the number of directory bits is 0, the DirectoryMemory doesn't use the numa_high_bit (mapAddressToDirectoryVersion and mapAddressToLocalIdx). Eliminating this if-statement and just setting numa_bit = block_size_bits + dir_bits - 1 would simplify the code and make it easier to debug directory mapping mods.

Show all issues

1. Brad Beckmann Sept. 12, 2012, 1:56 a.m. (Sept. 12, 2012, 1:56 a.m.)

   We could do that, but it seems awkward to set the numa_bit to be within the block offset when the number of directories is 1.  Actually, I think there may be an assertion somewhere else in the code that checks against that.
     

2. Joel Hestness Sept. 12, 2012, 4:58 a.m. (Sept. 12, 2012, 4:58 a.m.)

   I think you might be referring to the bitSelect and bitRemove assertions that the lower bit is less than or equal to the upper bit. These functions are only called from mapAddressToDirectoryVersion and mapAddressToLocalIdx when the number of directories is > 1 (dir_bits > 0), so collapsing this if-statement doesn't change the result of simulation. My previous note also says something stronger: numa_high_bit is set but never referenced when there is only one directory.

Ship It!