Dear list,
I am using gem5 full system simulation to run a 64-bit x86 application, and trying to capture the memory access towards the L1 DCache. I have successfully setup the whole full system simulation environment (Ubuntu 12.04 64-bit, Kernel version 3.2.1). I modified the code in configs/common/CacheConfig.py to equip my simulated system with L1 ICache and DCache, and intercept the communication between CPU and DCache with a common monitoring. My current observation is that, during the booting of the simulated system, it seems stuck at the *init_memory_mapping *procedure after almost half an hour. I past the output of the booting process below: ☁ term [master] ⚡ ./m5term localhost 3456 ==== m5 slave terminal: Terminal 0 ==== Linux version 3.2.1 (szw175@lrs-dwu01) (gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) ) #2 Tue Dec 27 14:24:46 EST 2016 Command line: earlyprintk=ttyS0 console=ttyS0 lpj=7999923 root=/dev/hda1 CPU: vendor_id 'M5 Simulator' unknown, using generic init. CPU: Your system may be unstable. BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 0000000020000000 - 00000000c0000000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) bootconsole [earlyser0] enabled NX (Execute Disable) protection: active DMI 2.5 present. No AGP bridge found last_pfn = 0x20000 max_arch_pfn = 0x400000000 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 CPU MTRRs all blank - virtualized system. found SMP MP-table at [ffff8800000f0050] f0050 init_memory_mapping: 0000000000000000-0000000020000000 I understand that such CPU<->DCache monitoring could be very time consuming, and it seems reasonable for such slow booting. However, I would like to inquire about two questions at this step, in case I didn't screw things up.. 1. Note that I am trying to monitor the cache access of an application code in the simulated OS, so basically it is meaningless to start the monitoring at the very beginning. So I am wondering if there is any chance that I can skip the monitoring during the OS booting; the monitoring can start right after the OS booting. My application code cannot run under the syscall simulation mode, so that's why I need the full system mode.. 2. Is there any "best practice" that I can use to boost the OS booting procedure under monitoring? Any advice or suggestion would be strongly appreciated! Thank you. Sincerely, Shuai
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
