I'll look today. Ali
Sent from my ARM powered mobile device On Jan 20, 2013, at 5:00 PM, "Steve Reinhardt" <ste...@gmail.com> wrote: > > >> On Jan. 18, 2013, 2:56 p.m., Nilay Vaish wrote: >>> Ali, Steve, can you take a look at this patch? >>> >>> In my opinion, all the changes being made to x86 tlb are pointless. >>> If we have to replicate everything with in the tlb for each thread, >>> why not create completely separate tlb structures. The cpu can just >>> make the translation call to the tlb corresponding to the thread which >>> needs the translation. > > I agree, if we're going to replicate all the state in the TLB, we might as > well just instantiate multiple TLB objects. > > I also don't understand why se.py needs to change; doesn't it already support > multithreaded jobs? > > I think the zeroreg fix could be committed as is though (I didn't look at it > closely, but if it's a real bug fix it should just go in). > > > - Steve > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1281/#review3871 > ----------------------------------------------------------- > > > On July 2, 2012, 11:21 a.m., Andrea Pellegrini wrote: >> >> ----------------------------------------------------------- >> This is an automatically generated e-mail. To reply, visit: >> http://reviews.gem5.org/r/1281/ >> ----------------------------------------------------------- >> >> (Updated July 2, 2012, 11:21 a.m.) >> >> >> Review request for Default. >> >> >> Description >> ------- >> >> Changeset 9074:8a6f47da502a >> --------------------------- >> x86: Fix SMT support (zeroReg, TLBs) >> >> >> ----------------------------------------------------------------------------------------------------------------------- >> - Fix the zeroReg problem >> >> There was an issue w/ the rename logic, which would assign a "previous" >> physical register to the ZeroReg architectural register in x86 (which, BTW, >> I don't believe exists in x86). This issue was giving problems for >> instructions squashed in threads w/ ID different from 0, sometimes allowing >> non-mispredicted instructions to obtain a value different from zero when >> reading the zeroReg. >> >> * changed cpu/o3/rename_map.cc >> >> ----------------------------------------------------------------------------------------------------------------------- >> - Replicated the pre-decoders >> >> There was an issue w/ the pre-decoders, as already pointed out by she user >> in the mailing list. >> >> * The new fetch stage has one decoder per thread, that might have fixed it >> >> ----------------------------------------------------------------------------------------------------------------------- >> - Replicated the TLBs (both ITLB and DTLB) >> >> This seems to be the simplest solution for x86, and it mimics design choices >> made for the Hyper-Threading technology in the P4. >> "Hyper-Threading Technology Architecture and Microarchitecture" from Marr et >> al. >> http://download.intel.com/technology/itj/2002/volume06issue01/art01_hyper/vol6iss1_art01.pdf >> >> * Added Num threads in: src/arch/x86/X86TLB.py >> If there is a better way to get this information, please let me know. >> >> * Added thread information to the page table: >> I am assigning a did to ask - ask was there and not used. I am not sure if >> it will work in FS mode (or if it is correct in this model, but it seems to >> be the more logical and simplest thing to do). >> >> ----------------------------------------------------------------------------------------------------------------------- >> - Changed the exit group sys call so now the program exits only when all the >> threads terminated >> >> Is there a better way to handle it? >> >> ----------------------------------------------------------------------------------------------------------------------- >> - Changed the se.py script to support SMT. >> It seems to work for both single and multi -threaded workloads. >> >> ----------------------------------------------------------------------------------------------------------------------- >> >> Test: >> >> * Are there any regression tests for x86 SMT? >> >> * Simple 4 threaded workload: >> >> Andreas-MacBook-Air:smt apellegr$ ../build/X86/m5.debug >> ../configs/example/se.py --maxinsts=500000000 --cpu-type=detailed --caches >> -n 1 -c >> '/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello' >> \gem5 Simulator System. http://gem5.org >> gem5 is copyrighted software; use the --copyright option for details. >> >> gem5 compiled Jun 28 2012 17:49:19 >> gem5 started Jun 28 2012 17:50:40 >> gem5 executing on Andreas-MacBook-Air.local >> command line: ../build/X86/m5.debug ../configs/example/se.py >> --maxinsts=500000000 --cpu-type=detailed --caches -n 1 -c >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello >> Global frequency set at 1000000000000 ticks per second >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7002 >> 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7003 >> 0: system.remote_gdb.listener: listening for remote gdb #2 on port 7004 >> 0: system.remote_gdb.listener: listening for remote gdb #3 on port 7005 >> **** REAL SIMULATION **** >> info: Entering event queue @ 0. Starting simulation... >> warn: instruction 'fnstcw_Mw' unimplemented >> warn: instruction 'fldcw_Mw' unimplemented >> Hello world! >> Done! >> Done! >> Done! >> hack: be nice to actually delete the event here >> Exiting @ tick 37617000 because target called exit() >> >> >> Diffs >> ----- >> >> configs/example/se.py f75ee4849c40 >> src/arch/x86/X86TLB.py f75ee4849c40 >> src/arch/x86/linux/syscalls.cc f75ee4849c40 >> src/arch/x86/pagetable.hh f75ee4849c40 >> src/arch/x86/pagetable.cc f75ee4849c40 >> src/arch/x86/pagetable_walker.cc f75ee4849c40 >> src/arch/x86/tlb.hh f75ee4849c40 >> src/arch/x86/tlb.cc f75ee4849c40 >> src/cpu/o3/rename_map.cc f75ee4849c40 >> >> Diff: http://reviews.gem5.org/r/1281/diff/ >> >> >> Testing >> ------- >> >> Test: >> >> * Are there any regression tests for x86 SMT? >> >> * Simple 4 threaded workload: >> >> Andreas-MacBook-Air:smt apellegr$ ../build/X86/m5.debug >> ../configs/example/se.py --maxinsts=500000000 --cpu-type=detailed --caches >> -n 1 -c >> '/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello' >> \gem5 Simulator System. http://gem5.org >> gem5 is copyrighted software; use the --copyright option for details. >> >> gem5 compiled Jun 28 2012 17:49:19 >> gem5 started Jun 28 2012 17:50:40 >> gem5 executing on Andreas-MacBook-Air.local >> command line: ../build/X86/m5.debug ../configs/example/se.py >> --maxinsts=500000000 --cpu-type=detailed --caches -n 1 -c >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop;/Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/loop/bin/x86/linux/loop >> /Users/apellegr/Research/svnrepo/viperII/gem5-viper/tests/test-progs/hello/bin/x86/linux/hello >> Global frequency set at 1000000000000 ticks per second >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7002 >> 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7003 >> 0: system.remote_gdb.listener: listening for remote gdb #2 on port 7004 >> 0: system.remote_gdb.listener: listening for remote gdb #3 on port 7005 >> **** REAL SIMULATION **** >> info: Entering event queue @ 0. Starting simulation... >> warn: instruction 'fnstcw_Mw' unimplemented >> warn: instruction 'fldcw_Mw' unimplemented >> Hello world! >> Done! >> Done! >> Done! >> hack: be nice to actually delete the event here >> Exiting @ tick 37617000 because target called exit() >> >> >> Thanks, >> >> Andrea Pellegrini > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
