An additional point is that read/write requests originating from a I/O device don't have a CPU id/PC.
Ali On Dec 10, 2008, at 8:19 AM, Joe Gross wrote: > Aah, I should clarify my comments then. I tried using the > Request::getPC() and similar functions, but I end up with an assertion > error because it's not a valid PC. Presumably once a request goes from > being a virtual address to a physical address this is all stripped > away > (Request::setPhys()) and the assertion error happens when you try to > read the PC. Since I don't know until I try to read the PC. I'm able > to > read the cpu/thread ID for several requests until I get an assertion > error on that as well. I'm hoping to find a reliable way to be able to > pull these values from every request that the memory system receives. > > I'll try using those flags you mention to classify where the request > originated, thanks. > > Joe > > > Steve Reinhardt wrote: >> I'm a little confused by your comments... the Request object has >> fields for pc, _threadID, and _contextID (which is a combined >> cpu/thread ID, equivalent to the cpu ID for non-multithreaded cores). >> I believe we're pretty good about setting them when appropriate. >> (Some operations, like writebacks, don't have meaningful values that >> you can assign there.) A pointer to the same request object is >> generally passed around to all the Packet objects associated with the >> original request, so ince that information is set it should not get >> lost in the memory system. >> >> There is an INST_READ flag in the request too that logically ought to >> signal an instruction fetch, though I see that the cores generally >> don't set that flag. That should be easy to fix though. There's >> also >> a VPTE bit that indicates a page-table read on Alpha, though what if >> anything other ISAs do to distinguish page-table accesses I don't >> know. >> >> Steve >> >> On Tue, Dec 9, 2008 at 9:43 PM, Joe Gross <[EMAIL PROTECTED]> wrote: >> >>> Hello, >>> >>> Is it possible to somehow determine the program counter, thread ID >>> and/or cpu ID from a Packet or Request object? It seems that >>> Request was >>> setup to be either contain this type of data or to contain only >>> physical >>> memory location data (stripping this data before it reaches the >>> memory >>> system). This information would be very useful for a memory >>> controller >>> to implement quality of service scheduling similar to what is in >>> POWER5. >>> It would also be nice to distinguish between page table lookups, >>> instruction fetches and load/store ops. I see that I can >>> reimplement the >>> cache component to be able to pass along the data (or possibly >>> assign a >>> priority and send only the priority of the request), but I'm >>> hoping that >>> there's an easier way that doesn't need to change so much of M5. Any >>> help is appreciated. >>> >>> Joe >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >>> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
