On Fri, 13 Apr 2012, Steve Reinhardt wrote:
On Fri, Apr 13, 2012 at 10:15 AM, Nilay Vaish <[email protected]> wrote:
On Mon, 9 Apr 2012, Joel Hestness wrote:
I'm hoping you guys could clarify a couple things for me:
1) It's not clear to me whether the messages passed between cache
controllers contain copies of the data being transferred, or if they just
contain pointers to locations which contain the data to be transferred.
This is important if, during a functional write in an intermediate state,
there is a copy of the data that is not pointed to by the caches that are
being updated. Can you clarify this?
Messages do contain data, and it is conceivable that during some
particular transcation, the data would be in the interconnection network
for some time. Hence, it is not possible at all times to honour a function
read/write request.
The way the classic memory system works is that interconnect components
that buffer state have to implement functional access methods that check
whether data in a buffered packet should be read or written (see for
example http://repo.gem5.org/gem5/file/5de232ed3a28/src/mem/bridge.cc#l440).
Brad and I have discussed this, and my impression is that this is also
feasible for Ruby, though Brad thinks it would be a headache to graft it on
to all the existing network models (paraphrasing his opinion from my faulty
memory). Nevertheless I think it should be done eventually. Brad tends to
push back, probably because he rightly fears that he would be the one to
end up doing it ;-).
The key point is that "not possible" is an overstatement.
When I wrote the phrase 'not possible', I only had the current setup in
mind. Last summer, Brad and I did discuss the possibility of involving
network components in satisfying functional requests, but we decided
against doing it.
2) Can you also clarify what the RubyPort::M5Port variable
access_phys_mem is supposed to indicate? If set, does this mean that the
physical memory actually contains the most up-to-date (possibly even dirty
cache line) data?
The access_phys_mem denotes whether or not a copy of the entire memory is
being maintained. You might know that as of now, programmed IO accesses do
not flow through ruby. So it is not possible to maintain a correct copy of
all the data. Hence, is separate copy of the memory is maintained, which
gets to see all the read/write operations.
Do we only turn on access_phys_mem for full-system simulations then?
Currently, it is set to true by default. It is set to false for the
various testers we have for ruby. But for se mode simulations, it is still
being set to true.
-------- Other scribblings for the record --------
Making this more complex is that in order for this functional access code
to work with other Ruby protocols, this solution will have to be generic
to
handle different types of intermediate states. I think the correct way
for
this to work is the following:
- On functional reads, find the cache(s) that contains the most recent
data (e.g. modified, exclusive or shared), and read the portion of the
line
that the functional access needs. If the line does not exist in caches,
just read from memory.
- On functional writes, find the cache(s) that contains the most recent
data (e.g. modified, exclusive or shared), and write the portion of the
line that the functional access needs. If the write switches the cache
line's state (e.g. exclusive to modified), update the appropriate state.
If the line does not exist in caches, simply forward the request on to
memory (this includes if we update lines in the shared state that aren't
dirty).
This is exactly what is being done. The problem is that at times none of
caches / memory controller may have the data.
My understanding is that, in addition to cases where the only valid data is
in the network (discussed above), there may also be cases where the data is
in the caches or memory but in some intermediate protocol state such that
it's not clear if it's the latest version, and it would require manual
effort to identify all the possible protocol states and whether they should
be considered valid for the purposes of responding to a functional request.
Again, this is a potentially faulty recollection based on prior
conversations with Brad.
I think most of the protocol states have been marked correctly wrt whether
or not they can satisfy functional read/write requests, though some states
may have been marked conservatively and therefore disallow functional
accesses. I think the only cases when we do not let the access succeed is
when
a) there is a read request and the latest data is in the network only,
b) there is a write request and the network holds the data.
Overall I would love to see full support for functional accesses in Ruby,
and we may reach a point where we really need to figure out how to make it
happen (maybe we are reaching it now). It's not a simple task, but maybe
we should brainstorm on how to simplify it, or decide that we can't do it
all at once but can have a plan to get there incrementally. Brad really
needs to be part of that discussion though, and he's off at the baseball
game today...
Steve
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
