Originally Posted by
micke_b
Ok, I assume that the schedule() function is the one switching the tasks so all I need to do the is to check which state the current task is being set to after being switched?
Correct. Inside the kernel, the model for putting a task to sleep is:
Code:
remove TASK_RUNNING from current task;
place task on wait queue for this object;
schedule();
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?
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.
Same for preemption, I just check what sate the current task is getting switched to?
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.
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?
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.