Review Board 2.0.15


Brandon Potter got review request #3113!

ruby: allows multiple instances of ruby to be invoked

Review Request #3113 - Created Sept. 14, 2015 and discarded

Information
Brandon Potter
gem5
default
2965
Reviewers
Default
Changeset 11093:3c32e2cb1c87
---------------------------
ruby: allows multiple instances of ruby to be invoked

This patch removes the restriction that there can only be a single ruby
system object in a given simulation. With the configuration supplied, it is
possible to run an instance of ruby with any of the supplied topologies.

The problem centers around the use of globals and static class members in the
ruby source. Conceptually, this prohibits multi-instance simulations
since the ruby systems end up sharing values which should be distinct. (The
earliest manifestation of this problem occurs when important runtime
components use shared variables for MachineType sanity checks which will
trigger failures.)

The idea behind the patch is to move as many as the statics/globals as
necessary into the ruby system object. The ruby system object acts as the
single point of reference for the child objects which needed the
globals/statics. With multi-instance runs, each ruby system object will
contain distinct values for the previous globals/statics. Unfortunately, this
requires passing the ruby system pointer throughout the object hierarchy and
may incur some minor performance overhead due to extra indirect references
through the ruby system object.

gem5/util/regress (to check builds) and custom tests (which use the new configuration)

Issue Summary

28 11 17 0
Description From Last Updated Status
I don't recall where we ended on the mapping function discussion. However, mapping functions will be specific to each RubySystem ... Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
This doesn't make sense. Cache entries should not need a pointer to the RubySystem. Certainly the caches have RubySystem pointers, ... Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Almost all of these functions are going to need to be RubySystem instance specific... Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Transient state shouldn't have pointers to persistent objects. Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Needs to be set in a different way with more appropriate abstraction (i.e. m_numa_high_bit should be private in RubySystem, and ... Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
ENTRY should not require a RubySystem pointer. Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Transient state shouldn't have access to a RubySystem pointer. Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Most of these changes shouldn't happen, since cache entries shouldn't have a RubySystem pointer. Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
These functions need to be moved into the RubySystem, since they are properties of each system instance. As evidence, in ... Joel Hestness Sept. 15, 2015, 7:37 a.m. Open
Does it make sense to leave these empty constructors around? Or are there times when a NetDest will be created ... Jason Lowe-Power Sept. 15, 2015, 9:19 a.m. Open
Another high-level question that applies to more than just this line: Why not have MachineType_base_count(machineType) as a method in RubySystem, ... Jason Lowe-Power Sept. 15, 2015, 9:19 a.m. Open
Review request changed
Updated (Feb. 22, 2017, 9:25 a.m.)

Status: Discarded