Re: [question] I doublt on timer interrput.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I get it !

I am sorry to spend your time so much, all trouble are came from one my low-level fault.

I put "++count_tick" in scheduler_tick(), but that function() can return before it!

This is one sample result:

[root@CCOSS_629884359 root]# cat /proc/sys/kernel/count_tick /proc/interrupts
157491
           CPU0
  0:     157390    IO-APIC-edge  timer
  1:         10    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:        111    IO-APIC-edge  i8042
 14:      57616    IO-APIC-edge  ide0
 15:          2    IO-APIC-edge  ide1
 16:          0   IO-APIC-level  uhci_hcd:usb1
 17:          0   IO-APIC-level  uhci_hcd:usb2
 18:        893   IO-APIC-level  eth0
NMI:          0
LOC:     157326
ERR:          0


We can see:

157491 > 157390 !

Yeah, I got it.

Thanks a lot again.

-liyu

Fawad Lateef wrote:

On 11/8/05, liyu <[email protected]> wrote:
Fawad Lateef Wrote:

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 !

Please see this URL:

http://lxr.linux.no/source/include/asm-i386/mach-default/do_timer.h#L20

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 ! :)

Thanks,

--
Fawad Lateef



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux