On Wed, Mar 4, 2009 at 12:01 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: > A short, probably incomplete list of possible solutions are: > 1. Build this on top of Alpha's load locked store conditional support. > 2. Add a locking mechanism to the caches and main memory.
On the face of it, #2 is the way to go... that's how it's done in real life. #1 sounds nice but would require the hardware to retry if the SC part fails which isn't realistic. My initial thought is to add a pair of flags to the memory request, "lock" and "unlock". (The name of the first one conflicts with the existing LL/SC flag, I know, but we'll deal with that later.) You'd set the lock flag on the first access of the sequence and unlock on the last. (I'm guessing they're all just two operations, so theoretically you might be able to get away without the unlock flag and just unlock on the second request you see, but that seems error prone.) Then you just require the cache/memory/whatever to not let anything else modify the block in the interim. However, there are some complications, particularly in atomic mode. If a write or readEx request comes in during a locked sequence in timing mode, it's easy enough to just buffer the request and respond only after the unlock. In atomic mode though, what do you do to the interloper? There's no general way to defer atomic transactions. (This is the first time I recall something being easier in timing mode than atomic... there's also a certain irony in atomic mode being unable to do atomic accesses easily!) I think there are two possible solutions: 1. Add a "retry" response code for atomic requests (along the lines of the error codes we alrady have in packet.hh) and then make sure that all the places where we issue atomic requests can deal with them appropriately. Oddly enough it's reminiscent of the LL/SC solution, though this is different since it only applies in atomic mode. 2. Force any cpu or device that wants to do locked accesses in atomic mode to do both the lock and unlock accesses back-to-back within the same event (e.g., in the same call to tick()). Neither of these sound particularly attractive. I like #2 better because #1 destroys the simplicity of atomic-mode accesses and I think would really complicate things like PTE updates where you're issuing requests from something that's not an instruction (and thus may not be so easy to retry). However it sounds like it could be a pretty ugly hack to force the AtomicSimpleCPU model to issue multiple uops in a single cycle... what do you think? It also arguably messes up the cpu's timing, but I don't care about that so much since if you really cared about timing you'd be using timing-mode memory anyway. As far as naming goes, I think all the current use of the term "locked" to indicate LL/SC operations is a mistake. From an elegance point of view I'd be in favor of renaming them all to something else. We can blame the Alpha folks for saying that LL means "load locked"; the original term was "load linked", which is what I think the MIPS instruction is officially named; the PowerPC version is called "load with reservation" or something like that. From a clarity point of view it's probably best to change the LOCKED flag to LLSC and isLocked() to isLLSC(). Then we could reclaim LOCK to really mean LOCK. I'd also be in favor of re-implementing SPARC swaps with this mechanism once we get it working and yanking the swap operations out of the memory system. Not a big deal, but no point in having needlessly redundant mechanisms. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
