[LITMUS^RT] Questions about tick mechanism in Kernel

[Björn Brandenburg]

On Apr 29, 2012, at 1:35 AM, Hang Su wrote:
> 
> I add a tick_test to struct rq in kernel/sched.c, like
> 
> struct rq{
>   unsigned long long tick_test ;
>   ...
>   ...
> }
> 
> and initialize it for each rq  in sched_init in kernel/sched.c, like
> 
> for_each_possible_cpu(i) {  
>   rq->tick_test = 0 ;
>   ...
>   ...
> }
> 
> Inside scheduler_tick function, which is called by timer code , I increase tick_test by one print it for each rq , like 
> 
> void scheduler_tick(void){
> ...
> ...
>  raw_spin_lock(&rq->lock);
>  update_rq_clock(rq);
>  update_cpu_load(rq);
>  /*edited by Hang*/
>    rq->tick_test++ ;
>    printk(KERN_DEBUG "THIS_CPU:%d TICK:%llu\n",cpu, rq->tick_test);
>  curr->sched_class->task_tick(rq, curr, 0);
>  raw_spin_unlock(&rq->lock);
> ...
> ...
> }
> 
> And I set Timer Frequency 1000 Hz, the result is like:
> 
> [  361.174006] THIS_CPU:0 TICK:361175
> [  361.174129] THIS_CPU:1 TICK:360959
> [  361.175004] THIS_CPU:0 TICK:361176
> [  361.175130] THIS_CPU:1 TICK:360960
> [  361.176006] THIS_CPU:0 TICK:361177
> [  361.176129] THIS_CPU:1 TICK:360961
> [  361.177005] THIS_CPU:0 TICK:361178
> [  361.177130] THIS_CPU:1 TICK:360962
> [  361.178006] THIS_CPU:0 TICK:361179
> [  361.178129] THIS_CPU:1 TICK:360963
> [  361.179004] THIS_CPU:0 TICK:361180
> [  361.179130] THIS_CPU:1 TICK:360964
> [  361.180006] THIS_CPU:0 TICK:361181
> [  361.180129] THIS_CPU:1 TICK:360965
> [  361.181004] THIS_CPU:0 TICK:361182
> [  361.181130] THIS_CPU:1 TICK:360966
> [  361.182006] THIS_CPU:0 TICK:361183
> [  361.182129] THIS_CPU:1 TICK:360967
> [  361.183004] THIS_CPU:0 TICK:361184
> [  361.183130] THIS_CPU:1 TICK:360968
> [  361.184007] THIS_CPU:0 TICK:361185
> [  361.184129] THIS_CPU:1 TICK:360969
> [  361.185004] THIS_CPU:0 TICK:361186
> [  361.185129] THIS_CPU:1 TICK:360970
> [  361.186005] THIS_CPU:0 TICK:361187
> [  361.186133] THIS_CPU:1 TICK:360971
> 
> The tick of CPU0 seems be to reasonable, but the tick of CPU1 does not. The gap of ticks between CPU0 and CPU1 is always 216. The timer represents how many seconds have elapsed since boot. It is a local timer for each CPU or global timer shared by all CPUs ? What is the reason for this gap ? In LITMUS pfair implementation, we have two ticksin pfair_state, curr_tick and local_tick. From comments, cur_tick is updated by the CPU and local_tick is the  local cpu currently executing. So, cur_tick is advanced by the same way as mine ? How does local_tick advance ?

Hello Hang Su,

the difference in tick counts can have several reasons. If you have dynamic ticks enabled, Linux will disable the tick interrupt when the processor is idle. (This is currently not supported by LITMUS^RT if you use the Pfair plugin.) Another reason for the difference in counts is that not all processors are started at the same time. Linux will start to boot on CPU 0 and enable other CPUs only later in the boot sequence. A delay of 216ms between processor initialization is entirely reasonable.

Regarding the Pfair plugin, the two tick counts (curr_tick and local_tick) exist to detect if some CPU is lagging behind the global state (i.e., if it failed to process some quantum boundaries). This can happen under QEMU/kvm, and also if there are long-running NMIs or if regular overheads become excessive.

Best regards,
Björn