[uClinux-dev] Re: soft_irq()
jwilliams at itee.uq.edu.au
Mon Mar 24 17:40:32 EST 2003
Paul McGougan wrote:
> You should bear in mind that the timer interrupt is also handled in two
> parts. Are you sure that you're not seeing the timer bottom half execute?
> The top half does hardware specific execution, updates jiffies, updates the
> execution times of processes (on SMP systems) and then schedules the timer
> bottom half. The bottom half updates the internal linux time (not jiffies,
> but wall time) and then process all kernel timers, on-calling functions for
> any that have expired. So quite a bit of stuff can happen in the timer
> bottom half.
OK got it now - my timer interrupt calls do_timer(), located in
/kernel/timer.c, where a bottom half is scheduled. So that explains
that at least. I've wound my HZ back to 15 to try get a better
understanding of what's happening (BTW has anyone seen the dreadful
compile-time error you get if HZ is not defined, or less than 10? It
chokes with "You lose. (timex.h)". That's it! bleugh!).
A related query: a ptregs pointer gets passed around most of this
interrupt stuff, to allow profiling and all sorts of interesting things.
I'm curious though, for performance reasons most of the various archs'
entry.S irq entry points save as little as possible on the stack
(subsequently aliased as a ptregs parameter to handle_irq()). For
instance, on a typical irq entry only the call clobbered regs are saved.
This means that only certain register values in the resulting ptregs
struct seen by the kernel are valid. Is this an issue, or is so little
done with the ptregs in the kernel that it doesn't really matter?
More information about the uClinux-dev