Correct. Inside the kernel, the model for putting a task to sleep is:
Originally Posted by micke_b
remove TASK_RUNNING from current task;
place task on wait queue for this object;
No. The code which calls schedule() should have already changed the state and moved it to the appropriate queue. If the change in state is always immediately prior to the call to schedule(), then the current time is a very good approximation of the time the task actually "went to sleep." The definition of when exactly the task goes from "awake" to "asleep" is debatable anyway.
That is is task1(t1) is on the cpu and gets blocked, then schedule() will change its state from TASK_RUNNIG to some thing else, so I can get this time?
For preemption, it is completely up to your scheduler to decide which tasks runs next -- that's the point of the scheduler. But yes, you can examine the current task, which should have been already placed in a sleep state, to figure out where and why it went to sleep, if you are interested in that information.
Same for preemption, I just check what sate the current task is getting switched to?
There is probably some kernel function which gets the CPU tick count, but I don't know what it is. I'm sure it's possible.
Also how do I capture time inside the kernel in a good way that don't "drift" in solaris and rt_linux we have gethrtime(), m using SUSE 10.3 form this project, is there any gethrtime() similarity?