I think something like that could work, although I won't be advocating for the forwarding snoop thing, since it seems as though ARM can support LLSC on uncachable accesses.
Ali On Thu, 15 Jul 2010 16:27:56 -0700, Steve Reinhardt begin_of_the_skype_highlighting end_of_the_skype_highlighting <[email protected]> wrote: > Alpha has to do the same thing on interrupts... the way this is > handled is that there's a per-thread lock flag in the CPU that gets > cleared on interrupts, and if that flag is not set then we fail the SC > without even sending it to the cache. (At least that's my > recollection of how it works.) Seems like ARM could/should do > something similar. > > Another possible way to handle these (that would be more realistic and > perhaps simpler overall) would be to forward all invalidation snoops > to the CPUs (which we can easily do), then have each CPU track the > address it has locked (if any) and clear the lock if it sees an > invalidation on the block it cares about. I think we didn't do it > that way because originally we did not send snoops to the CPU, but > with the current memory system it would be a minor change for M5 > classic (not sure about Ruby). It would also have the benefit of > eliminating the two separate LL/SC implementations in the caches and > in physmem. It's also a non-trivial change that might not be worth > it, and might be harder than you think it should be in Ruby. > > Steve > > On Thu, Jul 15, 2010 at 4:13 PM, Ali Saidi <[email protected]> wrote: >> >> ARM has an instruction that clears the lock flag (CLREX). To implement >> that in physical memory, it's easy enough, on the other hand with the >> cache >> it requires calling clearLoadLocks() on every block in the cache. >> >> Ali >> >> >> >> >> On Thu, 15 Jul 2010 16:01:09 -0700, nathan binkert <[email protected]> >> wrote: >>>> You're right that it could be done either way. I think the rationale >>>> is that this way you don't need to search a list to see if your >>>> address is on it. If the common case is that there are no locked >>>> blocks in the entire cache though then that's not a big deal since the >>>> list will be empty anyway. I can't think of any other reason. >>> >>> Why do you need a list of lock addresses? The only reason I can think >>> of is because of multiple threads. Is that what you're referring to? >>> I guess the other issue is that the lock address would have to be >>> checked on all stores in the system which could be a pain. Another >>> reason is that you're already accessing the tag for coherence >>> operations, so you might as well put the lock info there. You could >>> for example update MESI to have a "locked exclusive" or "locked >>> modified" state. >>> >>> >>> Nate >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
