I have one question about timer interrupt (i386 architecture).
As we known, the timer emit HZ times interrputs per second, and in i386. The interrupt handler will call scheduler_tick() each time (on i386 at least, both enable or disable APIC).
On my Celeron machine(IOW, only one CPU, not SMP/SMT), I defined a global int variable 'tick_count' in kernel/sched.c, and add one line of code like follow in scheduler_tick():
++tick_count;
but I found it is not same with content of the /proc/interrupts, and the differennt between them is not little.
> I have one question about timer interrupt (i386 architecture).
> As we known, the timer emit HZ times interrputs per second, > and in i386. The interrupt handler will call scheduler_tick() > each time (on i386 at least, both enable or disable APIC).
> On my Celeron machine(IOW, only one CPU, not SMP/SMT), I defined > a global int variable 'tick_count' in kernel/sched.c, and add one line > of code like follow in scheduler_tick():
> ++tick_count;
> but I found it is not same with content of the /proc/interrupts, > and the differennt between them is not little.
> I can not understand why that is.
> Any useful idea.
What I found in the kernel code is that scheduler_tick is called from two locations in the kernel (2.6.14-mm1) code (i386).
1) from kernel/timer.c in update_process_times which is called from arch/i386/kernel/apic.c and its calling depends on the CONFIG_SMP defined or not (see http://sosdg.org/~coywolf/lxr/source/arch/i386/kernel/apic.c#L1160) and as you don't have CONFIG_SMP enabled so its won't be called from here.
2) from sched_fork function in kernel/sched.c (http://sosdg.org/~coywolf/lxr/source/kernel/sched.c#L1414) and I think its called when newly forked process setup is going to be performed, and I think as from here scheduler_tick is called in your case, so you are getting different value for your variable tick_count
scheduler_tick might be called from somewhere else which I am missing so please CMIIW !
On Mon, 2005-11-07 at 14:05 +0800, liyu wrote: > Hi, all:
> I have one question about timer interrupt (i386 architecture).
> As we known, the timer emit HZ times interrputs per second, > and in i386. The interrupt handler will call scheduler_tick() > each time (on i386 at least, both enable or disable APIC).
> On my Celeron machine(IOW, only one CPU, not SMP/SMT), I defined > a global int variable 'tick_count' in kernel/sched.c, and add one line > of code like follow in scheduler_tick():
> ++tick_count;
> but I found it is not same with content of the /proc/interrupts, > and the differennt between them is not little.
>> I have one question about timer interrupt (i386 architecture).
>> As we known, the timer emit HZ times interrputs per second, >>and in i386. The interrupt handler will call scheduler_tick() >>each time (on i386 at least, both enable or disable APIC).
>> On my Celeron machine(IOW, only one CPU, not SMP/SMT), I defined >>a global int variable 'tick_count' in kernel/sched.c, and add one line >>of code like follow in scheduler_tick():
>> ++tick_count;
>> but I found it is not same with content of the /proc/interrupts, >>and the differennt between them is not little.
>> I can not understand why that is.
>> Any useful idea.
>What I found in the kernel code is that scheduler_tick is called from >two locations in the kernel (2.6.14-mm1) code (i386).
>1) from kernel/timer.c in update_process_times which is called from >arch/i386/kernel/apic.c and its calling depends on the CONFIG_SMP >defined or not (see >http://sosdg.org/~coywolf/lxr/source/arch/i386/kernel/apic.c#L1160) >and as you don't have CONFIG_SMP enabled so its won't be called from >here.
>2) from sched_fork function in kernel/sched.c >(http://sosdg.org/~coywolf/lxr/source/kernel/sched.c#L1414) and I >think its called when newly forked process setup is going to be >performed, and I think as from here scheduler_tick is called in your >case, so you are getting different value for your variable tick_count
>scheduler_tick might be called from somewhere else which I am missing >so please CMIIW !
static inline void do_timer_interrupt_hook(struct pt_regs *regs) { do_timer(regs); #ifndef CONFIG_SMP update_process_times(user_mode(regs)); #endif /* * In the SMP case we use the local APIC timer interrupt to do the * profiling, except when we simulate SMP mode on a uniprocessor * system, in that case we have to call the local interrupt handler. */ #ifndef CONFIG_X86_LOCAL_APIC profile_tick(CPU_PROFILING, regs); #else if (!using_apic_timer) smp_local_timer_interrupt(regs); #endif
}
That is the code in 2.6.12, but 2.6.13.3 also same with it at least. So we call scheduler_tick() HZ times per second, both enable SMP or disable it.
Nod, I agree with your words, the scheduler_tick() do not same with timer interrupt handler on call times. but I guess it should be more than jiffies, beacause of other functions also can call it (for example, as Lateef said, sched_fork().)
I think that
scheduler_tick() might be called from somewhere
is not exact.
We may note, it do not be EXPORT_SYMBOL_*()ed , so it only can be called from kernel core, not kernel modules. Such a few places we can find it use LXR or grep.
I use setup one sysctl integer variable to watch the value of 'count_tick', Do this way have any problem? I found some value skips, but I think it is normal case.
However, I will make a experiemnt that write one hook like do_timer(), as Love said
PS: if our scheduler_tick() is not called every timer interrput, the compute of task timeslice also is not exact ?!
> >What I found in the kernel code is that scheduler_tick is called from > >two locations in the kernel (2.6.14-mm1) code (i386).
> >1) from kernel/timer.c in update_process_times which is called from > >arch/i386/kernel/apic.c and its calling depends on the CONFIG_SMP > >defined or not (see > >http://sosdg.org/~coywolf/lxr/source/arch/i386/kernel/apic.c#L1160) > >and as you don't have CONFIG_SMP enabled so its won't be called from > >here.
> >2) from sched_fork function in kernel/sched.c > >(http://sosdg.org/~coywolf/lxr/source/kernel/sched.c#L1414) and I > >think its called when newly forked process setup is going to be > >performed, and I think as from here scheduler_tick is called in your > >case, so you are getting different value for your variable tick_count
> >scheduler_tick might be called from somewhere else which I am missing > >so please CMIIW !
> static inline void do_timer_interrupt_hook(struct pt_regs *regs) > { > do_timer(regs); > #ifndef CONFIG_SMP > update_process_times(user_mode(regs)); > #endif > /* > * In the SMP case we use the local APIC timer interrupt to do the > * profiling, except when we simulate SMP mode on a uniprocessor > * system, in that case we have to call the local interrupt handler. > */ > #ifndef CONFIG_X86_LOCAL_APIC > profile_tick(CPU_PROFILING, regs); > #else > if (!using_apic_timer) > smp_local_timer_interrupt(regs); > #endif > }
> That is the code in 2.6.12, but 2.6.13.3 also same with it at least. > So we call scheduler_tick() HZ times per second, both enable > SMP or disable it.
Yes, this is the thing which I missed
> Nod, I agree with your words, the scheduler_tick() do not same with > timer interrupt handler on call times. but I guess it should be more > than jiffies, beacause of other functions also can call it (for example, > as Lateef said, sched_fork().)
> I think that
> scheduler_tick() might be called from somewhere
> is not exact.
> We may note, it do not be EXPORT_SYMBOL_*()ed , so it only can be called > from kernel core, > not kernel modules. Such a few places we can find it use LXR or grep.
By saying __might_be_called_from_somewhere__ I meant that I am missing some-other place __with-in_the_kernel_code__ from where it is called, which you pointed to me (about do_timer.h) :)
> I use setup one sysctl integer variable to watch the value of 'count_tick', > Do this way have any problem? I found some value skips, but I think it is > normal case.
If you are declaring count_tick as a global variable (without static) in sched.c then you can just use it in your test module by specifying extern for your variable
> However, I will make a experiemnt that write one hook like do_timer(), > as Love said
> PS: if our scheduler_tick() is not called every timer interrput, the > compute of task timeslice > also is not exact ?!
Yes, I am now sure that it will be called for every timer interrupt ! :)
>>>What I found in the kernel code is that scheduler_tick is called from >>>two locations in the kernel (2.6.14-mm1) code (i386).
>>>1) from kernel/timer.c in update_process_times which is called from >>>arch/i386/kernel/apic.c and its calling depends on the CONFIG_SMP >>>defined or not (see >>>http://sosdg.org/~coywolf/lxr/source/arch/i386/kernel/apic.c#L1160) >>>and as you don't have CONFIG_SMP enabled so its won't be called from >>>here.
>>>2) from sched_fork function in kernel/sched.c >>>(http://sosdg.org/~coywolf/lxr/source/kernel/sched.c#L1414) and I >>>think its called when newly forked process setup is going to be >>>performed, and I think as from here scheduler_tick is called in your >>>case, so you are getting different value for your variable tick_count
>>>scheduler_tick might be called from somewhere else which I am missing >>>so please CMIIW !
>>static inline void do_timer_interrupt_hook(struct pt_regs *regs) >>{ >> do_timer(regs); >>#ifndef CONFIG_SMP >> update_process_times(user_mode(regs)); >>#endif >>/* >> * In the SMP case we use the local APIC timer interrupt to do the >> * profiling, except when we simulate SMP mode on a uniprocessor >> * system, in that case we have to call the local interrupt handler. >> */ >>#ifndef CONFIG_X86_LOCAL_APIC >> profile_tick(CPU_PROFILING, regs); >>#else >> if (!using_apic_timer) >> smp_local_timer_interrupt(regs); >>#endif >>}
>>That is the code in 2.6.12, but 2.6.13.3 also same with it at least. >>So we call scheduler_tick() HZ times per second, both enable >>SMP or disable it.
>Yes, this is the thing which I missed
>>Nod, I agree with your words, the scheduler_tick() do not same with >>timer interrupt handler on call times. but I guess it should be more >>than jiffies, beacause of other functions also can call it (for example, >>as Lateef said, sched_fork().)
>>I think that
>>scheduler_tick() might be called from somewhere
>>is not exact.
>>We may note, it do not be EXPORT_SYMBOL_*()ed , so it only can be called >>from kernel core, >>not kernel modules. Such a few places we can find it use LXR or grep.
>By saying __might_be_called_from_somewhere__ I meant that I am missing >some-other place __with-in_the_kernel_code__ from where it is called, >which you pointed to me (about do_timer.h) :)
>>I use setup one sysctl integer variable to watch the value of 'count_tick', >>Do this way have any problem? I found some value skips, but I think it is >>normal case.
>If you are declaring count_tick as a global variable (without static) >in sched.c then you can just use it in your test module by specifying >extern for your variable
>>However, I will make a experiemnt that write one hook like do_timer(), >>as Love said
>>PS: if our scheduler_tick() is not called every timer interrput, the >>compute of task timeslice >>also is not exact ?!
>Yes, I am now sure that it will be called for every timer interrupt ! :)
