Hello,

I have been playing with time in m5 syscall emulation mode and had a couple of 
issues:

First of all I believe there is a bug in the times() syscall implementation 
(sim/syscall_emul.hh). The current clocks value passed to the userland is:
        int64_t clocks = curTick * OS::M5_SC_CLK_TCK / SimClock::Int::s;

This evaluates to a wrong expression. Now, according to the man page all the 
tms buffer values are supposed to be in clock ticks. Thus a more appropriate 
expression for it would be:
        int64_t clocks = tc->getCpuPtr()->tickToCycles(curTick);
 
Secondly, I have implemented the nanosleep() system call. I believe that the 
appropriate way to do this would be suspending (tc->suspend()) the 
ThreadContext and re-activating (tc->activate(delay)) after the sleep duration 
(please correct me if I am mistaken). This however led to a peculiar behaviour 
with O3 in SMT mode:
1. in FullO3CPU<Impl>::suspendContext (cpu.cc) the CPU _status is set to Idle, 
regardless whether there are other running contexts in the CPU. Thus a thread 
sleeping leads to all the other SMT threads sleeping.

2. in FullO3CPU<Impl>::activateContext (cpu.cc) we schedule a tick event after 
the delay parameter passed, effectively overwriting CPU's tickEvent and moving 
all threads of the processor tick(delay) ticks forward. Is this the intended 
behaviour or is it a bug? Clearly in my case it is not helpful since the point 
of getting a thread to sleep relative to the other threads' time.

Thank you,
Ioannis

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to