On Fri, Sep 3, 2010 at 11:44 AM, DRAM Ninjas <[email protected]> wrote:
> Greetings, > > After lots of debugging, here is a not-so-big patch that fixes the errors > in the shared L2 cache. I believe this is working correctly as I've run > several non-trivial workloads to completion, but the simulations have been > non-deterministic, so I can't say with utter certainty, but I'm relatively > certain this works. > > Thanks a lot for your efforts to find and fix the bug. > Most of the issues stemmed from some assumptions made about which level of > cache is the last level before the main memory, so perhaps a new flag along > the lines of isLowestBeforeMainMemory_ would be useful. > > This sounds good to me. I'll look at the patch after the weekend (its long weekend so no work, except catching up on emails. :) ) and will try to add your suggested flag in it. - Avadh > Let me know if anything looks off in it. > > -Paul > > > On Mon, Aug 23, 2010 at 6:13 PM, avadh patel <[email protected]> wrote: > >> Hi Paul, >> >> Did you figure out the issue why the cache queue is filled up and not >> emptied? >> >> Thanks, >> Avadh >> >> On Mon, Aug 16, 2010 at 11:43 PM, DRAM Ninjas <[email protected]>wrote: >> >>> So after trying to figure out what is going on, I have a theory as to why >>> this is failing. >>> >>> It all comes down to this case: >>> >>> 793 * Message contains a valid argument that has >>> 794 * the state of the line from lower cache >>> 795 */ >>> 796 queueEntry->line->state = *((MESICacheLineState*) >>> message.arg); >>> >>> In the shared L2 case the "lower cache" is the memory which doesn't send >>> a message.arg since the line should just be marked exclusive. >>> >>> I guess a short term fix would be to just check if message.arg == NULL, >>> then set the line to MESI_EXCLUSIVE. Really, the check should be more along >>> the lines of >>> >>> #ifdef ENABLE_L3_CACHE >>> if (type_ == L3_CACHE) >>> #else >>> if (type_ == L2_CACHE) >>> #endif >>> >>> >>> Now, while this fixes the seg fault it also stalls out the pipeline with >>> thousands of: >>> >>> Adding event:Event< Signal:Bus_broadcast Clock:16882 arg:0x1e75410> >>> Executing event: Event< Signal:Bus_broadcast Clock:16882 arg:0x1e75410> >>> Bus cant do addr broadcast, pending queue full >>> >>> I will try to look at this tomorrow -- maybe finishing the broadcast >>> isn't clearing out the pendingQueue entry for some reason...? >>> >>> -Paul >>> >>> On Thu, Aug 12, 2010 at 10:32 PM, DRAM Ninjas <[email protected]>wrote: >>> >>>> The cache questions continue. >>>> >>>> I just tried to compile the current master branch and set up a shared L2 >>>> cache configuration with the following simconfig file: >>>> >>>> -stats run0.stats >>>> >>>> -logfile run0.log >>>> -corefreq 2000000000 >>>> -cache-config-type shared_L2 >>>> -cores-per-L2 2 >>>> >>>> >>>> built using 'scons c=2' >>>> >>>> I get this backtrace from GDB almost immediately: >>>> >>>> #0 0x00000000005cdbe1 in >>>> Memory::MESICache::CacheController::complete_request (this=0x260a210, >>>> message=..., queueEntry=0x260a288) at >>>> ptlsim/build/cache/mesiCache.cpp:797 >>>> #1 0x00000000005d3035 in >>>> Memory::MESICache::CacheController::handle_lower_interconnect ( >>>> this=0x260a210, message=...) at ptlsim/build/cache/mesiCache.cpp:349 >>>> #2 0x00000000005d325d in >>>> Memory::MESICache::CacheController::handle_interconnect_cb ( >>>> this=0x260a210, arg=0x256f6b0) at >>>> ptlsim/build/cache/mesiCache.cpp:835 >>>> #3 0x00000000005d5178 in Memory::P2PInterconnect::controller_request_cb >>>> (this=0x1e9ba80, >>>> arg=<value optimized out>) at ptlsim/build/cache/p2p.cpp:82 >>>> #4 0x00000000005c25a8 in Memory::MemoryController::wait_interconnect_cb >>>> (this=0x1ea5010, >>>> arg=0x1ea5088) at ptlsim/build/cache/memoryController.cpp:238 >>>> #5 0x00000000005c29db in Memory::MemoryController::access_completed_cb >>>> (this=0x1ea5010, >>>> arg=<value optimized out>) at >>>> ptlsim/build/cache/memoryController.cpp:206 >>>> #6 0x00000000005c3b1c in Memory::Event::execute (this=0x2543090) >>>> at ptlsim/cache/memoryHierarchy.h:109 >>>> #7 Memory::MemoryHierarchy::clock (this=0x2543090) at >>>> ptlsim/build/cache/memoryHierarchy.cpp:380 >>>> #8 0x00000000005ec37d in OutOfOrderModel::OutOfOrderMachine::run >>>> (this=0x162c2c0, config=...) >>>> at ptlsim/build/core/ooocore.cpp:2034 >>>> #9 0x000000000063b476 in ptl_simulate () at >>>> ptlsim/build/sim/ptlsim.cpp:1092 >>>> #10 0x00000000005a7e56 in sim_cpu_exec () at qemu/cpu-exec.c:302 >>>> #11 0x0000000000419e73 in main_loop (argc=0, argv=<value optimized out>, >>>> envp=<value optimized out>) >>>> at qemu/vl.c:4246 >>>> #12 main (argc=0, argv=<value optimized out>, envp=<value optimized >>>> out>) at qemu/vl.c:6234 >>>> >>>> >>>> I'm going to build a debug version to see if I can track this down, but >>>> just wanted to see if anyone has seen this before ... >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>> >>> _______________________________________________ >>> 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
