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
@@ -511,8 +511,13 @@ 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.
--HPS
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
