On Thu, May 5, 2011 at 11:48 AM, zhenyu sun <[email protected]>wrote:
> Hi DRAMninjas, > > Thank you very much for your explanation. > I understand ur points. The problem I have now is I wanna figure out where > is the "long chain of events" in the code. Is it in the event_queue. > Because I saw one line in the code. > In the cache_access_cb: > memoryHierarchy_->add_event(signal, delay, (void*)queueEntry); > You should read this line as 'delay cycles from now, execute the function pointed to by signal, and pass it queueEntry as an argument'. signal and delay get set based on whether this is a cache miss or hit. So let's say the access time for this cache is 5 cycles. After 5 cycles, the cache_hit_cb() function will be executed. That function will probably schedule the event for cache_access_completed_cb(), and then that function will generate an event that calls wait_interconnect_cb(), which will then generate a call to P2PInterconnect::handle_interconnect_cb() ... etc, etc. (note: these might not be the actual call chains -- these chains tend to be pretty long so I don't remember them exactly). Each of these events might have some delay associated with it. In other words, cycles are ticking by while the pipeline is waiting for the cache request to resolve. I think the final terminating point for a cache request is in cpuController:: finalize_request() at which point the cache request is signal'd to be done in the pipeline and execution continues. I don't look at the ooocore/pipeline code very often so I can't tell you where the actual IPC statistics are computed (probably in the writeback phase somewhere), but that's the overall scheme by which IPC is implicitly determined. I hope that was clear enough ... Once this function is called, > > and in the definition of add_event > event->setup(signal, sim_cycle + delay, arg); > > > so does it mean the delay is finally added on the sim_cycle which is used > in the ipc calculation: number of instruction/sim_cycle? > In other words, does the add_event function which is the member of class > Event influence the global variable? > > Thank you very much. > I am really urgent to know this answer. > > Best, > Zhenyu > > ------------------------------ > Date: Thu, 5 May 2011 11:16:18 -0400 > Subject: Re: [marss86-devel] How the latency of cache access is reflected > on the ipc? > From: [email protected] > To: [email protected] > CC: [email protected] > > > I think the answer to this question is sort of complicated. If you look > down below, the delay variable is basically used to schedule either the > cache hit event delay cycles in the future or a cache miss event delaycycles > in the future. > > The code you pointed out is just a small step in the life of a cache > request. Essentially at each point in the simulation, the simulator decides > which function to call and how far in the future. So a cache hit will > execute in x cycles, but a cache miss might go out to memory and take x+100 > cycles to complete. This *total* latency to service a request is the key. > The pipeline will send a cache request out, wait for it to complete, and > then retire it. This is really what determines the IPC. What you've pointed > out in the cacheController is one step along this long chain of events which > ends in the request being 'completed' and the instruction moving forward in > the pipeline. > > Please correct me if I misunderstood your question. > > On Fri, Apr 29, 2011 at 10:36 PM, zhenyu sun > <[email protected]>wrote: > > Hi everyone, > > I am working on the CPU performance study under different cache hit > latencies. > > In the cacheController.cpp: > > if(hit) { > delay = cacheAccessLatency_; > > > > If the CPU encounter a stall caused by write access (dependency or buffer > is full), how does the 'delay' influence the ipc. > In other word, in which part of the code the delay is added on the > sim_cycle? > > Thanks a lot. > > Zhenyu Sun > > > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
