Quoting Steve Reinhardt <ste...@gmail.com>: > On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt <ste...@gmail.com> wrote: >> 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 [...] > > Another advantage of #2 is that atomic-mode atomicity comes "for free" > without touching the memory system at all. This is nice since it > gives you a baseline that will work on any memory system (e.g., Ruby). > > There's also some possibility that we could avoid implementing > timing-mode locking in main memory with this approach, by making the > reasonable restriction that if you want to run in timing mode then you > have to use caches. That may not hold if we have to deal with locked > uncached accesses... I know these exist in real life, but I'm hoping > that that's one of the "features" we can avoid by only running modern > 64-bit software. Gabe, do you know off hand if there are locked > uncached accesses in any of the code you've run so far? > > Steve > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
I haven't reached a conclusion on what to do, but I have a few thoughts. First, I don't know if we'd be able to use #2 to get away with not implementing locking in the main memory for timing accesses. It would be impossible to do a read and write of a location in the same event because you'd have to wait around for each to complete. You'd either have to force all other accesses to wait around which might be a big performance hit. Also things might get really sticky with speculative accesses, although I think that may be true in general. I like the idea of having lock and unlock flags, although I think it would be a good idea to not allow intervening operations even from the same source. With that restriction, locks could set up a condition where you'd only allow an access to happen if it was an unlock. If everything obeyed the rule of a lock and then an unlock that would guarantee atomicity and has the nice property that you don't have to keep track of -who- the access was originally from, just where the access was to. It may be next to impossible to actually know who has a lock if you have, for instance, a shared cache intervening. You could lock the address all the way up though, I suppose. All of the accesses I mentioned before and all of the CPU maintained data structure updates can happen with a single load-op-store, although I could believe there's some other ISA that needs something more elaborate. I have never directly seen an uncached, locked access, but I've been completely ignoring locked accesses in general up to now so I wouldn't consider that very authoritative. I'd be pretty surprised (but not shocked) if something somewhere used them. As far as how to make atomic mode atomic (which -is- weird), I don't really like either of the options you mentioned either. The first one seems more naturally analogous to timing mode, but then why do we need atomic mode? The second one limits the effects of supporting this sort of instruction/operation, but it would probably really complicate the CPU and I'd bet have a lot of unintended consequences. I've been thinking about this in the background and I haven't been able to come up with a better idea though. I'll keep trying. Gabe _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
