You can mark a section of main memory as not cachable so it's not like an I/O device. But, sort of, the description in the architecture reference manual says there is a global monitor that checks the accesses.
Ali On Jul 15, 2010, at 7:10 PM, Steve Reinhardt wrote: > Really? Doesn't that imply that you're snooping on uncacheables in real life? > > On Thu, Jul 15, 2010 at 4:38 PM, Ali Saidi <[email protected]> wrote: >> >> 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 >> > _______________________________________________ > 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
