For #1 and #4, these are pretty much the same right? The contextID is really all possible sharers rather then just threadContext. Seems like you should keep the meaning of contextID as it pertains to thread and then generate a "sharerID" that would be a superset of the contextIDs. Objects that dont have an explicit thread but are sharing can just offset off the highest contextID. would that make sense?
For #2, I'd prefer not to further complicate that ThreadContext interface. For #3, I started on that patch but thought I would have to work after Lisa committed her changes and I envisioned having a system where you could either manually state the sharers or the system would figure it out for you. Figuring this out automatically all the time is an acceptable solution ... :) I thought the easiest way would be to use the port connections to traverse the system since something is already done for the snoop Port registration.The only trick would be for CPUs with multiple threads you need to ask out how many contexts it's going to share. On Wed, May 25, 2011 at 1:57 PM, nathan binkert <[email protected]> wrote: > Hi Everyone, > > I'm trying to work with Lisa's patch to convert cache vector > statistics to record data on a per-context basis where context is > anything that executes instructions. (Some things were per-CPU and > some things were per-thread and neither make sense). She added a > parameter to each cache called "num_sharing_contexts" that would tell > the cache how many contexts could send that cache a request. Indexing > into the vector was done by taking req->contextId and doing a modulo > with num_sharing_contexts. DMA controllers would all get stuck in a > special additional bin. > > There are two things I don't like about this scheme. First, > configuring the parameter is a pain in the butt. Second, it's hard to > compare statistics from two different caches because their indexes are > different. Third, you can't separate out DMA controllers. > > So, what I did was get rid fo num_sharing_contexts and use the number > of contexts that were registered with the system with > registerThreadContext (adding one for the DMA controllers). This > works for the common case, but doesn't work with the MemTester because > the memtester doesn't have a thread context to register. > > I see a few options for solving this problem: > 1) Separate out the contextId allocation from registerThreadContext so > things like DMA controllers and memtesters can get allocated a > contextID. > 2) Create a base class for ThreadContext that is far simpler than the > current thread context and use that when registering. > 3) Figure out contextID not by registration, but instead by doing a > traversal of the memory system. This would require that we have some > sort of indication differentiating memory objects that can generate > requests and thus require a contextID and memory objects that can't > (caches, dram, pio devices, etc.). We add a constructor parameter to > the MemObject base class. > 4) Add a separate registration function for non Thread Contexts. > > Thoughts? Ideas? > > Nate > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
