On Sun, 26 Oct 2014, Steve Reinhardt wrote:
On Sun, Oct 26, 2014 at 2:23 PM, Nilay Vaish <[email protected]> wrote:
Marc Orr asked me the same question last year. I am pasting the examples
I gave him:
a. the data in the message is stale, but the sender does not know about
it. Take a look at the MESI CMP directory protocol. In the case when an L1
controller (A) sends a PUTX to the L2 controller, it is possible that the
L2 controller has already transferred the ownership to some L1 controller
(B). In this case, it is possible that there are two message buffers that
contain messages from A and B to the L2 controller, but it is message from
B which has the 'right' data.
Interesting. I can see how this technically could be a problem, but it
seems like a pretty unlikely corner case. Have you seen it happen in
practice, and if so, what was the functional read for? I suppose I just
have a hard time imagining an actual program that has a lot of contention
on a block that ends up being used as a parameter to a system call. I
guess it could happen with a syscall that's specifically for
synchronization, like futex.
About an year, I had actually committed a patch that returned the first
data value it found (after making sure that no controller had the block in
a stable state). I ran into the case illustrated above and I had to
rollback the patch.
b. no data is present in the message and the receiver will infer that the
data it has is correct since the message did not have any data.
This seems like it should pretty easy to fix... if you're querying the
message to see if it has relevant data, then if the address matches but
there is no data, you should just return false. I'd think there'd be a
protocol-independent way to determine that a message has no data. It's
similar to the idea that you have to check the valid bit in the cache, you
can't just look for a tag match.
I doubt we can do this in protocol independent way. I think the presence
/ absence of data is decided by the type of the message which is a
protocol specific enum.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
