OK.This explains that if a process gets "migrated" from one CPU to another, the time is not "affected". But it still doesn't explain if the process gets scheduled back to the same CPU.
Just in case I have not explained my question clearly, let me explain it from the schedular's perspective.
Lets assume that there are 3 processes, P1 an MPI process, P2 and P3 are otehr active processes. Assume that the timeslice for each process is 10ms.
During the first time slice that P1 gets, it calls the MPI_Wtime(), stores it in "start" variable and does half of the solver. Unfortunately, at this ponit the timeslice of P1 got over, and the OS schedules P2 and P3 before getting back to P1. So it takes 20ms, before P1 gets its share of CPU back, at which point it completes the remaining half of the solver, and calculated MPI_Wtime() and stores it in end. In short, it required two timeslice for the MPI process to complete.
If the "wall clock" (a global counter) and there is no way for me to "save" the value when the context switch occured from P1 to P2 and re-initialize counting as soon as context switches from P3 back to P1, then it would include the time spent by the process P2 and P3 as well (20ms in this case)
.
PS: To keep it simple, I am not considering the preemption that might happen due to an interrupt, or the overhead of context switching.
MPI_Wtime() returns the elapsed time since some arbitrary time in
the past. It is a measure of "wallclock" time, not of CPU time or
anything.
On 5/4/2012 3:08 PM, Jingcha Joba wrote:
Lets say I have a code like this
start = MPI_Wtime()
<Run the solver>
stop = MPI_Wtime();
What happens when right after start=MPI_Wtime(), the
timeslice of the process ( from the operating system's
perspective not the MPI process) is over, and the operating
system schedules a next process, after saving the context
switch, and eventually this application would resume, once its
process is scheduled back by the os.
Does MPI_Wtime() takes care of storing/updating the time when
this happens?
Of course, part of the answer lies in the implementation of
Wtime.
On Fri, May 4, 2012 at 3:53 AM, Jeff Squyres <jsquyres@cisco.com> wrote:
On May 3, 2012, at 2:02 PM, Jingcha Joba
wrote:
> Not related to this question , but just curious, is
Wtime context switch safe ?