On 7/6/10 9:36 PM, "Steve Reinhardt" <[email protected]> wrote:
> Just to add my two cents:
>
> - As far as the memory system goes, I thought the drain protocol took
> care of the case where an object thought it was drained but then
> wasn't anymore. For example, if there's a request at the L1 and the
> L2 thinks it's drained, then when that request goes from the L1 to the
> L2 then the L1 may report that it's drained but the L2 should start
> saying that it's not. It's only when all the objects in the system
> simultaneously claim to be drained that it's really drained.
Yes, if any simobject returns a positive number when drain() is called after
all the drain counts reach 0, drain() will be called again on all objects to
make sure that the the outstanding access hasn't simply moved to another
location in the memory system.
One caveat is that there isn't any checking about the number of times an
object calls process() on the drain object, so even if you return 2 from the
drain() call (meaning that you'll call process on the drain object twice to
reduce the outstanding count by two when you're object is drained()),
nothing stops you from calling it three times meaning that some object might
still have an outstanding transaction. There could be something like this
going on.
> - Ignoring the timing callback in AtomicSimpleCPU does seem a bit like
> cheating, but it doesn't seem completely out of the question to me if
> none of the other methods pan out. Just make sure you add a comment
> explaining why you're doing that. Add a warn() message too and I
> would sleep easy.
>
> - I'm also confused about why you would have queued messages in
> SimpleTimingPort when you're in atomic mode. Something seems fishy
> there.
I think this is probably the source of the issue.
Thanks,
Ali
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
