Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 10:28:47 PM Hans Petter Selasky wrote:
> On 01/17/17 20:46, Ian Lepore wrote:
> >>> Does this matter for the first tick? How often is configtimer() called?
> >> >
> >> > As I said, it is called at runtime when profclock is started / stopped, not
> >> > just at boot.  Those changes at runtime probably have existing callouts
> >> > active and your change will not process any callouts until the next hardclock
> >> > tick fires (but only because you are setting nextcallopt to the bogus
> >> > 'next' value).
> > On some platforms, configtimer() can be called quite often.  Power
> > saving modes can change the frequency of the timer, and systems that
> > suppport such dynamic frequency scaling call configtimer()
> > (via cpu_et_frequency()) to handle the changes.
> 
> Hi,
> 
> I propose the following patch then:
> 
> diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
> index 7f7769d..5ae925b 100644
> --- a/sys/kern/kern_clocksource.c
> +++ b/sys/kern/kern_clocksource.c
> _at__at_ -511,8 +511,13 _at__at_ configtimer(int start)
>                          state->nexthard = next;
>                          state->nextstat = next;
>                          state->nextprof = next;
> -                       state->nextcall = next;
> -                       state->nextcallopt = next;
> +                       /*
> +                        * Force callout_process() to be called
> +                        * instantly, so that the correct value of
> +                        * "nextcall" can be computed:
> +                        */
> +                       state->nextcall = SBT_MAX;
> +                       state->nextcallopt = now + 1;
>                          hardclock_sync(cpu);
>                  }
>                  busy = 0;
> 
> 
> Then there is no problem having to wait for the next tick or anything, 
> like John Baldwin pointed out.

Note that 'nextevent' remains a full 'timerperiod' out (now + timerperiod)
and so the first clock interrupt is still 'timerperiod' time away and
any callouts are delayed by that amount of time.  Also, I think you could
set nextcallopt to 'now' rather than 'now + 1'.

You might still want to adjust 'nextevent' to schedule the next interrupt
to be sooner than 'timerperiod' though.  You could just set 'nextevent' to
'now' in that case instead of 'next'.

-- 
John Baldwin