This thread is going in several directions here at once... glad to have some lively discussion. Rather than follow up directly on all the pieces, I'll just throw some various comments in here in one spot, and try to organize the discussion a bit:
1. Going back to Brad's email, and the near-term issue: I'm fine with having a facility for integrating an *optional *backing store in a protocol-independent fashion, a la Nilay's current patch. I can see the value for debugging and for "correctness decoupling" in early stages of development. While I realize that providing this option means that some protocols may never get past the debugging phase, I agree with Nate that that's not a desirable state of affairs. Because of that and the sequential consistency issue, I'm OK with this facility only as a non-default option. 2. If the backing store is just a debugging option, then we can't use it as the default implementation mechanism for functional accesses, which is where a lot of the additional discussion has come in. There have been a lot of good points made, but nothing that has really changed my opinion. I think it's critical that we have a shared view of what functional accesses are good for. My view is somewhere in the middle, I think; the usages I see for functional accesses are: a. memory state initialization (kernel/binary loading at sim startup) b. syscall emulation c. lightweight interactive debugging (e.g., gdb support) It's pretty awkward for a functional access to fail, but given the difficulty in defining how a functional access interacts with weaker consistency models, I'm fine with functional reads having a "best effort" definition in terms of the value that actually gets returned. For initialization, the memory system is dormant, so this should not be an issue. For syscall emulation and debugging, functional accesses are typically injected from the CPU that is doing the syscall or running the code being debugged, so I think that the odds of there being problems are vanishingly small. If we do run into problems, I think the right direction to go is not to "fix" functional accesses themselves, but to address things at a higher model. E.g., maybe we should think about adding a hook to allow a protocol to perform acquire/release operations before/after syscalls, or maybe we should dive in and add some sort of threading capability that lets us do emulated syscalls using timing memory accesses. Note that neither of these options involves either making functional accesses more sophisticated or getting rid of them entirely. Given this "best effort" definition, it's not appropriate to use functional accesses in the checker part of a memory tester. I think a memory tester should implement its own backing store. Alternatively, if enabling the optional backing store also allows one to automatically perform checking of the "live" values against the backing store, then the memory tester could use that capability, which still would not involve the tester issuing any functional accesses. 3. To Marc's point: IIRC, there is already some code in the functional access path (in the classic memory system at least) that detects the case where you get a partial hit on data in a message or something like that. This can happen even in conventional protocols if you issue an unaligned access (e.g., because you're pretending you're an x86 or something). I think the code currently calls panic(), which is not helpful. I'd say the right way to do that is to add a retry mechanism where a functional access that fails because of a partial hit is automatically retried under the covers as a sequence of byte accesses. IMO that's the kind of thing that could wait until it's needed, though, and might never actually be needed. This issue is really orthogonal to the "best effort" issue with respect to the consistency model though. 4. While it may be the case that the current design of Ruby does not lend itself to easy implementation of functional accesses in a protocol-independent fashion, I still believe that there's no fundamental obstacle to this, and that Ruby could be improved to enable this. Steve On Mon, Oct 27, 2014 at 2:21 PM, Marc Orr via gem5-dev <[email protected]> wrote: > I want to clarify what I believe is an oversight: > With respect to functional reads, it's not really correct to just "return > the first valid value found in some ruby structure." > > A relaxed protocol (e.g. the quickrelease paper by Blake Hechtman et al.) > might allow two versions of a cache block to exist in different caches, > such that different parts of the cache line are being read by different > threads For example, thread 1 on core 1 might be writing the first 32 bytes > of a 64-byte cache line while thread 2 on core 2 is writing the second 32 > bytes. There is no race here because the different versions of the cache > line are "merged" as appropriate. > > A more complete solution would need to track cache blocks at a byte/word > granularity and assemble the functional read's return value from one or > more cache blocks that it finds in the ruby system. > > Thanks, > Marc > > On Mon, Oct 27, 2014 at 2:37 PM, Nilay Vaish via gem5-dev < > [email protected] > > wrote: > > > On Mon, 27 Oct 2014, Beckmann, Brad wrote: > > > > I agree with Joel that this has been an interesting discussion. While > >> there are questions about how these situations can occur and what is the > >> best way to fix them, there doesn't seem to be anyone resisting the fact > >> that this patch should be checked in, correct? I think it is very > >> important that we not require protocols to always provide completely > >> functional memory. > >> > > > > > > I still need to look into how checkpoints will work. With the current > > code, the existing checkpoints will not work at all. > > > > -- > > Nilay > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
