Hi guys, A couple things: There have been some statements about the backing store being sequentially consistent or encouraging/reinforcing such a model. I may be overlooking something, but I'm pretty sure that's not true. The consistency model is enforced by the core load-store queues, which issue requests to the RubyPorts. Since the RubyPort access_phys_mem causes memory accesses to read/write the backing store at the end of the cache access rather than when the cache is updated, the only thing that changes is the timing of the memory access' atomic read or modify portion. However, the ordering of accesses, as enforced by the LSQs, will remain largely unchanged. You can still have race conditions in buggy simulated code if, for instance, necessary fences are missing. I'm pretty sure this means that using the Ruby backing store enforces the same consistency model as enforced by the LSQs, and that model can be as strong or weak as desired.
While the majority of gem5-gpu functional accesses are reads, functional writes do include futex-like handling. However, for implementing drivers/runtimes with close interaction with CPU code, it is also very desirable to pass return values for device-targeted function calls (e.g. simulator-aided memory allocations and device parameter get/set) and IO control handling. These currently constitute a larger portion of the functional writes in gem5-gpu simulations. Also, while we haven't really considered tackling it, some of these values could be passed through CPU core registers like other pseudo-instruction calls, but things like device configurations involve structs that would still need to be copied in memory. I really appreciate this discussion. Thanks! Joel On Sun, Oct 26, 2014 at 5:10 PM, Steve Reinhardt via gem5-dev < [email protected]> wrote: > On Sun, Oct 26, 2014 at 2:29 PM, Nilay Vaish via gem5-dev < > [email protected] > > wrote: > > > On Sun, 26 Oct 2014, Andreas Hansson via gem5-dev wrote: > > > > Hi guys, > >> > >> I see how functional accesses make sense when the system is starting or > >> drained, or potentially for reads while it is running. To inject > functional > >> writes at runtime seems like asking for trouble though. As > >> > > > > System calls can cause functional writes. Even if there are no > functional > > writes, you can still run into problems with functional reads. > > > > Actually I would argue that writes are easy---functional writes identify > every copy of data associated with a particular location and update all of > the copies atomically, so from that point on any read will return the new > value, until that address is written again. This should be more than > adequate for nearly all system calls that write to memory (such as read()), > since you really shouldn't have data races between user threads and buffers > you've passed to the OS. > > Functional reads can be trickier, as Nilay has pointed out, though I'm > still curious just how common those tricky cases are. > > It may be that, if there are system calls where we do expect data races to > be possible, then we should not be using functional accesses for those. I > haven't really thought this through yet though. > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
