Thread: Where do a task get "wakeuped", blocked, preempted?

Hi,

Where in the linux kernel do a task get:

1. "wakeuped" - that is after a task being blocked and the resource it been waiting for gets free, the task gets woken up, where in the kernel code do this happen? Some signal sent? Or is every task that gets "enqueued" in kernel/sched_rt.c - enqueue_task_rt() woken up:ed?


2. blocked, when a task gets blocked where in the kernel code is it taken of the cpu? Can I get the time of this from schedule() in kernel/sched.c? how? even if I work in the real-time class?


3. preempted, when a higher priority task gets runnable, where in the code do the current task get of the cpu and put back into a running queue? Can I get the time of this from schedule() in kernel/sched.c? how? even if I work in the real-time class?

I'm going to implement a custom scheduler so I need to get the time of these events. I'm thankful for any help, tips is also welcome.

I'm working in the real-time class and the 2.6.23.9 kernel

Originally Posted by micke_b

1. "wakeuped" - that is after a task being blocked and the resource it been waiting for gets free, the task gets woken up, where in the kernel code do this happen? Some signal sent? Or is every task that gets "enqueued" in kernel/sched_rt.c - enqueue_task_rt() woken up:ed?

The kernel sets the task state to TASK_RUNNING | TASK_INTERRUPTIBLE and then sticks it on the run queue.

2. blocked, when a task gets blocked where in the kernel code is it taken of the cpu? Can I get the time of this from schedule() in kernel/sched.c? how? even if I work in the real-time class?

Tasks can block in zillions of places. To block a task you remove TASK_RUNNING and remove it from the run queue, and place it on a wait queue specific to the resource being waited on.

3. preempted, when a higher priority task gets runnable, where in the code do the current task get of the cpu and put back into a running queue? Can I get the time of this from schedule() in kernel/sched.c? how? even if I work in the real-time class?

A task can only be preempted on an interrupt or a blocking system call. Normally this interrupt is a time slice boundary, but it could be some other kind of interrupt which causes a high priority task to become servicable. Most interrupts are handled by kernel threads, but the timer interrupt is basically just a call to the scheduler.

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? 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?

Same for preemption, I just check what sate the current task is getting switched to?


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?

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.

Originally Posted by brewbuck

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();

Ok, so when schedule() is called it puts this task, the one that just got placed on the sleep queue, off the CPU and pick the next one to run, that is the one with the highest priority? So the I can figure out what just happen and what will happen next here.

Ok, thanks for the help, just going to find out how to capture the ticks then I got all the pieces I need.