On Mon, Jan 31, 2011 at 12:28 PM, Gabe Black <[email protected]> wrote:
> This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/455/ > > On January 31st, 2011, 7:14 a.m., *Steve Reinhardt* wrote: > > I don't see why this is necessary. > 1. I don't think caches request address ranges, they are just the default > responder on buses where they sit on the memory-side of the bus. > 2. As far as the timing issue, I don't know whether this diff makes things > more realistic, but if timing is an issue then we ought to be able to just > change the cache code to make it pass uncached accesses through more quickly. > > I don't think it's bad, necessarily, it just appears to be fixing something > that I thought already worked, so if it's broken I'd like to understand > better what the problem is before we commit to this being the fix. My > apologies if I missed some previous email discussion; I've been bad about > keeping up with m5-dev email lately. > > And why does it apply to x86 only? Is there something special about x86 that > requires this? > > I don't think 1 is correct. Caches request an address range, it just > defaults to the whole address space. > > OK, I think I see part of the problem. In terms of how it's *supposed* to be, we're both right... the caches request the whole address space, but they're supposed to be the "default responder" meaning that they get forwarded a request only if there is no other target. It's explained here: http://repo.m5sim.org/m5/rev/9af6fb59752f Unfortunately it looks like the comment in the message about "The default bus responder on all other buses is now the downstream cache's cpu_side port" didn't get implemented, and the caches just connect to regular ports, which means they would conflict with something else on the bus. > > I'm guessing that's so you can set up banked caches. > > No, it's because it's broken ;-). > I implemented this because M5 wouldn't work without it because the none > memory ports were conflicting with the cache address ranges. > > If the caches were properly set up as default responders then this shouldn't be a problem. > For 2, I wasn't talking about simulated time, I was talking mostly about > simulated time. The uncached accesses would pass through unmolested (assuming > there wasn't something with a transmission delay) but then you'd have to poke > each cache, port interface, and intermediate bus on the way. This isn't > really a big change, it's just making the config scripts route some ports > through caches and some around them. I really doubt interrupt traffic on a > real CPU goes through the cache, although I don't know that for a fact. > > I doubt these happen often enough that simulation time is an issue. As far as realism, it depends on what "through the cache" means... certainly uncached accesses don't do a cache lookup, but they probably do flow through/across many of the same buffers/queues/wires as cacheable accesses on their way out the door, and that's more what the current model represents. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
