kernel hacking, plz help

Hi, as a nob kernel hacker I want to capture in the rt-class the following events: task gets preempted, task gets blocked, task wakes up from being blocked, task tick. I got the following questions:


1. When a rt-task is about to be preempted in the rt-class the task_preempt_curr_rt(..) is called, is this correct?

2. When a rt-task is running in the CPU the function task_tick_rt(..) is called every tick, 1 tick = 1ns by default. Is this correct?

3. When a rt-task gets blocked the function dequeue_task_rt(..) is called, is this correct?

4. When a rt-task wakes up from being blocked, either enqueue_task_rt(..) or requeue_task_rt(..) is called, is this correct?

5. If i want to account for CPU-time in a rt-task, which clock to use? will sched_clock() be a good choice?


I'm pretty sure about 1 and 2, but not so sure about 3, 4 and 5, any help is welcome.

Thanks.

Quote:

---

Originally Posted by micke_b

Hi, as a nob kernel hacker I want to capture in the rt-class the following events: task gets preempted, task gets blocked, task wakes up from being blocked, task tick. I got the following questions:


1. When a rt-task is about to be preempted in the rt-class the task_preempt_curr_rt(..) is called, is this correct?

---

Not sure, but it sounds about right.

Quote:

---

2. When a rt-task is running in the CPU the function task_tick_rt(..) is called every tick, 1 tick = 1ns by default. Is this correct?

---

I surely hope that you don't get a tick interrupt every 1ns - even a modern dual core processors would be spending 100% of the time handling interrupts at this rate of interrupts - the clock-cycles on a 2GHz processor are 0.5ns long, so you would be looking at performing an interrupt every other clock-cycle.

The time may be measured in nanoseconds, but it's certainly not interrupting every one of them - it's either measuring chunks of say 500-10000 ns at a time, or, if more precise time is required, it's using other ways to determine the time (e.g. the TSC).

Quote:

---

3. When a rt-task gets blocked the function dequeue_task_rt(..) is called, is this correct?

---

Sounds plausible.

Quote:

---

4. When a rt-task wakes up from being blocked, either enqueue_task_rt(..) or requeue_task_rt(..) is called, is this correct?

---

Makes sense to me.

Quote:

---

5. If i want to account for CPU-time in a rt-task, which clock to use? will sched_clock() be a good choice?

---

If you are on single processor core, I'd use TSC - it's relatively precise, and as long as you are not measuring TOO often, I'd use JUST a RDTSC and store the 64-bit result. If you want really short intervals with good precision, you'd need a serializing instruction to ensure that the RDTSC instruction isn't "misplaces" by out-of-order execution. For example "CPUID; RDTSC" would do the job - but this increases the overhead of the RDTSC - so if you want don't need to have very precise measurement, you are probably better off just using the RDTSC itself.

Quote:

---

I'm pretty sure about 1 and 2, but not so sure about 3, 4 and 5, any help is welcome.

Thanks.

---

--
Mats

Thanks for the answers.

Of course you are right about the tick func not being called every ns. But I'd want to get the time every tick. And for this you mean that TSC is better then sched_clock()?

with TSC you mean from include/asm/tsc.h? the: get_cycles(..)?

I also noted in this file the get_cycles_sync(..) and tsc_init(..) functions. Do I need to init this clock()?



In the header it says about get_cycles_sync(..):
/* Like get_cycles, but make sure the CPU is synchronized. */

synchronized with other CPUs? If so I only need to call the get_cycles(..) and this will give me the number of clock cycles? sinze tsc_init() was called? Is it automatically called?

thanks

Yes, get_cycles() should do that you want, generically.

No, sync just means that it's forcing the instructions before RDTSC to be "forced out" before the TSC is being read.

sched_clock() may give the same result, but with a whole heap of extra overhead, as it uses multiple different sources to get the current time.

Note that if you switch from one CPU to another, RDTSC is not a good solution - I think sched_clock() would be the right solution then - but I'm not sure. This is because TSC can shift from one CPU to another.

--
Mats

Ok, thanks again.

No-one that knows how long this tick-interrupt is? how often do task_tick_rt() get called? how to check?

Quote:

---

Originally Posted by micke_b

Ok, thanks again.

No-one that knows how long this tick-interrupt is? how often do task_tick_rt() get called? how to check?

---

If you record (say in a large-ish array) the TSC if each time you get into the task_tick_rt(), you should be able to tell, I expect.

However looking at:
http://lxr.linux.no/linux/kernel/sched_rt.c#L233
leads to:
http://lxr.linux.no/linux/kernel/sched.c#L3333

It seems like it's called as often as HZ says - which is one of the configurations in "xconfig" or "menuconfig" in your Linux kernel.

--
Mats

Ok, when I check my menuconfig I find the "timer frequenzy" set to 250HZ is this it? so every 4ms then?

Quote:

---

Originally Posted by micke_b

Ok, when I check my menuconfig I find the "timer frequenzy" set to 250HZ is this it? so every 4ms then?

---

Yes, that would be the one.

If you want more finegrain timing, you can probably crank it up to 1000Hz -> 1ms. Much more than that and you will suffer from too much overhead, not enough work done, as not only does the interrupt itself take up time, but everything done in a timer-tick (including the scheduler-related work, but also ticking up time outs etc) will be done every time. Possibly 10000Hz is reasonable on a modern processor - but with some loss of performance for sure.

--
Mats

Ok, thanks Mats, really helped a lot as usually. :)