ThreadContext suspension / activation in O3 SMT - nanosleep syscall | Review Request

Information
Submitter:	Ioannis Ilkos
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

This is a patch fixing the ThreadContext suspension / activation described in http://www.mail-archive.com/m5-dev@m5sim.org/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.

Testing Done

Looks fine to me... anyone else?

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.

Ioannis Ilkos July 29, 2010, 6:01 a.m. (July 29, 2010, 6:01 a.m.)

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).

john@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.

src/arch/alpha/linux/process.cc (Diff revision 1)

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 July 29, 2010, 2:24 a.m. (July 29, 2010, 2:24 a.m.)
```
I would be in favour of doing that, yes.
```

Ioannis Ilkos July 29, 2010, 3:45 a.m. (July 29, 2010, 3:45 a.m.)

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.

src/cpu/o3/cpu.cc (Diff revision 1)

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.

Ioannis Ilkos July 29, 2010, 5:21 a.m. (July 29, 2010, 5:21 a.m.)

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)

src/sim/syscall_emul.hh (Diff revision 1)

Some of the lines in this function look >80 chars; if so they should be wrapped.  (Anyone know if there's a way to check this in ReviewBoard?)

Diff:

Revision 2 (+56 -16)

Show changes

	src/arch/alpha/linux/linux.hh
	src/arch/alpha/linux/process.cc
	src/cpu/o3/cpu.cc
	src/sim/syscall_emul.hh

You have a pending review.

Review Board 2.0.15

ThreadContext suspension / activation in O3 SMT - nanosleep syscall

Screenshots

Files

Diff: