Hi, I am curious about the handling of dependencies / order in the cache subsystem. So far, I have looked at the function find_dependencies in *Controller, and have a few related questions:
1) AFAICS, there is no mechanism that orders stores, correct? Note that on x86 / AMD64, stores must be written back in-order to not break the memory semantics. This can cause significant stalls in the post-retire store buffers. Probing can commence out-of-order, but the actual write-back has to happen in-order. I know that in PTLsim / Marss this is not a behavioural problem (i.e. programs cannot observe this), because the actual memory content is updated in ReorderBufferEntry::commit (thread.ctx.storemask) in-order already. It would still be nice to model that extra in-order handling somewhere. 2) How are the dependencies enforced? I have to admit I frequently get lost with all the *_cb and handle_* functions and the multiple levels of requests etc. I have, however, failed so far to understand how dependants are woken up (only found CPUController::wakeup_dependents), but that one should not apply for the dependencies in the normal coherent CacheController. I also did not find any retry path which will make the stalled request check its dependencies periodically, in case there is no external wakeup. 3) How is it made sure that memory instructions only depend on OLDER requests? I would guess the "continue" in find_dependency should really be a "break", since when we reach our own request, don't we know that we have checked all older requests? If that list of pendingRequests is not in-order, what other mechanism can we use to make sure that things are always dependent on older requests? 4) I wanted to use the dependency mechanism to be able to have a memory request that will wait on all older stores (and loads) to ripple through the memory subsystem, first. Using an mfence in the core *should* be enough, but I would need to know when the (implicit in Marss86) store buffer has drained and know that stores are actually drained in-order. Since both is not in place, my attempt to model that particular request as a store has failed, so far. Many thanks for pointers, Stephan _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
