The contextId in a request corresponds to the CPU/context that generated the request.
Lisa On Tue, Sep 7, 2010 at 4:15 PM, Malek Musleh <[email protected]> wrote: > Hello, > > I have a question in regards to the context ID field of the pkt->req > with use of selective statistics update. > > If I trying to selectively turn on statistics update for a specific > core, would using the pkt->req->contextId() be a meaningful approach > to associate to do so? > > I mean a meaningful approach in the sense that does it correspond > directly to the core that is reading the packet, or does it correspond > to the core that generated the original pkt->req? > > If it is the case that the contextId read from pkt->req->contextId() > corresponds to the core executing that code than I can use it, but if > it corresponds to the core that generated the pkt->req, is there some > other method in which I can get the cpu ID of the core? > > I get also it depends on which function I am tracking the stats in, > for example timingAccess for an L1 cache only gets called by the core > that its connected to, so in that case pkt->req->contextId would match > the core upon which its executing on, while in other cache functions > such as ::handleResponse or ::handleSnoop, it might not match? > > Just to give an overview as to why I need this, is because I am trying > to eliminate the cycles in the statistics output that are caused by > Synchronization events (e.g. threads spinning on locks). By passing > in the software ID of the executing program via a pseudo instruction, > I can pinpoint specifically which thread is about to enter > synchronization so I can choose when to collect stats or not. > > Thanks for any help that can be provided. > > Malek > _______________________________________________ > 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
