There are two steps: 1. Transmitting the writeback request from the last-level cache across the memory bus to the main memory. 2. The latency of main memory from when it receives a request to when it sends the corresponding response (if any).
The main memory write latency (and in fact any main memory parameter) only affects #2. The latency of #1 is determined by the cache block size, the memory bus width, and the memory bus clock rate. There qill also be queuing delay for #1 if the bus is occupied when the cache first tries to send the writeback request, but this queuing delay is only affected by the amount of time that other requests and responses occupy the bus, not the latency between requests and responses. Steve On Mon, Jul 5, 2010 at 7:28 PM, sheng qiu <herbert1984...@gmail.com> wrote: > hi Steve, > > Thank you very much for your patient. i may not state my doubt clearly. I > expect if the writeback take up the memory bus longer than usual, then the > read request maybe delayed by lack of memory bus bandwidth. So the total > sim_ticks may be larger. i just want to know whether M5 include this impact. > That's why i expected that set latency larger for pkt->iswrite() may lead > larger sim_ticks than original. So maybe i misunderstand this latency? Or > can you tell me where i can find the relevant codes of this part? > > Thanks, > Sheng > > > > _______________________________________________ > m5-users mailing list > m5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
