FYI, also, neither do writebacks. Lisa
On Wed, Dec 10, 2008 at 5:12 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > 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 > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
