On Mon, 9 Apr 2012, Joel Hestness wrote:
Hey guys,
I've dug into this some more, and this challenge looks pretty complex.
For some detail on what's happening, I'm trying to integrate another
simulator in with gem5, and I need to use functional accesses to get data
that this other simulator needs in the functional aspects of it's
simulation.
As I mentioned previously, when using Ruby, if a cache line happens to be
in the busy state on a functional access (e.g. if it is being passed
between caches in most protocols), the RubyPort doesn't know how to grab
the data on a functional read, or which data to update on a functional
write. The current code handles read-write and read-only data in the
caches, but doesn't handle this busy state.
@Brad, Nilay:
I tracked down some conversation you've had about functional access in a
previous thread (here:
http://www.mail-archive.com/[email protected]/msg12120.html
"[gem5-dev] Functional Memory
Accesses in Ruby"), in which you articulate the exact problems that I'm
dealing with here. Unfortunately, the assumption that Ruby should not
handle functional access when a cache line is in an intermediate state has
given me some major problems with the integration I'm working on (at least
5 of my 12 preliminary benchmarks).
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.
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.
Thanks!
Joel
-------- 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.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
