Re: alternate high-res-timers patch comments (II)

[Jim Houston]

> Here are more comments/questions on Jim's alternate high-res-timers
> patch.  Some of this is just to understand the code.
> 
> a.  Why return here and skip profiling?
>     Is this an intermediate (high-res) timer interrupt that shouldn't be
>     used for profiling?
> 
>  inline void smp_local_timer_interrupt(struct pt_regs * regs)
>  {
>         int cpu = smp_processor_id();
> +
> +       if (!run_posix_timers((void *)regs))
> +               return;
> 
>         x86_do_profile(regs);
> 
> b.  In kernel/id2ptr.c,
> 
> <id_free_cnt>:  change cnt to count; just a style thing.
> Linux doesn't use many abbreviations, which makes it easier on
> everyone not having to remember "what is the abbreviation that code
> uses for <whatever>?".
> 
> sub_alloc() is recursive.  How bounded is it?  32 calls max?
> I'm not totally against recursion, but it needs to be *well-bounded*.
> 
> Same for sub_remove().
> 

Hi Randy,

Yes, the code fragment in a) above is how the timer code shares the 
APIC timer interrupt.  There is an in-kernel "Posix style" timer
which is used to generate the profile tick.  This still needs
a bit of work to allow the profile tick rate to be set.  It defaults
to HZ.  In the long run, it might make sense to call the profiling
code from the "case TICK" in check_expiry() perhaps generalizing the interface
so that it would call through a function pointer.  There are a few 
bits of code that would benifit from having in-kernel repeating timers.
An example would be the code which syncs the hardware clock every 18 minutes.

Yes, the id allocator uses a recursive approach.  This has been discussed
before. It is well bounded, has a tiny stack frame and will never
require more than 6 levels of nesting.  I have been following the changes
George has made to his version.  This "simple problem" is a real time sink.

Jim Houston - Concurrent Computer Corp.