> On 2010-07-29 08:46:47, Steve Reinhardt wrote: >> Thanks! Just a couple minor things... >> >> - Did you test this with the other CPU models besides O3? I'm guessing you >> did and O3 was the only one that broke, but I just wanted to verify that. >>
If you are referring to the SMT contexts, this has been tested only with O3. As far as I understand, only O3 and InOrder support SMT. Trying to run ALPHA_SE with inorder SMT however (with the m5 repo version) results in a segfault so I have not looked into it (the programs executed just do a printf() and exit so nothing special about them). j...@orion:~/m5vanilla$ build/ALPHA_SE/m5.debug configs/example/se.py --inorder --caches -c "../m5t/strange;../m5t/test" M5 Simulator System .. .. info: Entering event queue @ 0. Starting simulation... Segmentation fault Concerning nanosleep itself, it works with O3 and InOrder. However, I just tested it with SimpleCPU (--timing) and a single workload and it looks like for some reason activateContext() does not skip the cycles. An excerpt from the trace: 19114000: system.cpu: syscall nanosleep called w/arguments 0,13,4831386864,4831386864 19114000: global: nanosleep: sleeping for 2000200000 cycles 19114000: system.cpu: SuspendContext 0 19114000: system.cpu: ActivateContext 0 (2000200000 cycles) 19114000: system.cpu: syscall nanosleep returns 0 19114000: system.cpu T0 : @__libc_nanosleep+24 : call_pal callsys : IntAlu : 19114000: system.cpu: Fetch I am guessing that this is a different problem with the activateContext() and the fetchEvent scheduling of SimpleCPU however. I do not think the changes will break anything, but please run the regressions to be on the safe side. > On 2010-07-29 08:46:47, Steve Reinhardt wrote: >> src/arch/alpha/linux/process.cc, line 470 >> <http://reviews.m5sim.org/r/68/diff/1/?file=834#file834line470> >> >> This is a broader question (not just for Ioannis): does it make sense to >> proactively add this to the syscall tables for the other ISAs too? I don't >> see anything ISA-specific here. > > Timothy Jones wrote: > I would be in favour of doing that, yes. According to the linux kernel sources: #define _STRUCT_TIMESPEC struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; #endif It basically depends on sizeof(long) for each ISA. If all ISAs supported are 64bit it can be moved to ISA-independent code. > On 2010-07-29 08:46:47, Steve Reinhardt wrote: >> src/cpu/o3/cpu.cc, line 714 >> <http://reviews.m5sim.org/r/68/diff/1/?file=835#file835line714> >> >> I'm curious why the state is set to idle even if there is one active >> thread... I see that the existing test above in deallocateContext is similar >> but I don't understand that one either :-). Adding a comment to cover this >> would be helpful. Comment added. Basically deallocateContext schedules the removal of the thread from the active list in the next cycle (and the deallocated ret value is always false as soon as we call deallocateContext with a delay, which we do) - Ioannis ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/68/#review115 ----------------------------------------------------------- On 2010-07-29 13:01:13, Ioannis Ilkos wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/68/ > ----------------------------------------------------------- > > (Updated 2010-07-29 13:01:13) > > > Review request for Default. > > > Summary > ------- > > This is a patch fixing the ThreadContext suspension / activation described in > http://www.mail-archive.com/[email protected]/msg07307.html and implementing > the nanosleep() syscall (albeit without the signal-relevant parts) for > AlphaLinux. > > Changes in O3: > - The tick scheduling was removed from activateContext() and moved into > activateThread(). It seems more natural since activateContext() either calls > activateThread() or schedules it. In the case of scheduling there is no need > to schedule ticks prematurely. > - suspendContext() and haltContext() check the number of active threads > before setting CPU _status to Idle. > > > Diffs > ----- > > src/arch/alpha/linux/linux.hh b28e7286990c > src/arch/alpha/linux/process.cc b28e7286990c > src/cpu/o3/cpu.cc b28e7286990c > src/sim/syscall_emul.hh b28e7286990c > > Diff: http://reviews.m5sim.org/r/68/diff > > > Testing > ------- > > > Thanks, > > Ioannis > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
