On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote:
> On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> > ticks and jiffies start at zero. During boot in initclocks(), we
> > reset them:
> >
> > /* sys/kern/kern_clock.c */
> >
> > 89 int ticks;
> > 90 static int psdiv, pscnt; /* prof => stat divider
> > */
> > 91 int psratio; /* ratio: prof / stat */
> > 92
> > 93 volatile unsigned long jiffies; /* XXX Linux API for
> > drm(4) */
> > 94
> > 95 /*
> > 96 * Initialize clock frequencies and start both clocks running.
> > 97 */
> > 98 void
> > 99 initclocks(void)
> > 100 {
> > 101 ticks = INT_MAX - (15 * 60 * hz);
> > 102 jiffies = ULONG_MAX - (10 * 60 * hz);
> > 103
> > 104 /* [... ] */
> >
> > The idea here (committed by dlg@) is sound. We reset ticks and
> > jiffies to near-rollover values to catch buggy code misusing them.
> >
> > But! That jump from zero to whatever violates valid assumptions made
> > by correct code, too.
>
> Assumptions made by what code? Does it exist in the tree?
First, even if the code did not exist, wouldn't it be simpler to not
do the jump? No?
Second, with rare exception, all kernel code using ticks/jiffies
assumes ticks/jiffies does not advance more than once every 1/hz
seconds on average.
In timeout_add(9), we assign an absolute expiration time relative
to the current value of ticks. Code calling timeout_add(9) before
initclocks() cannot account for the jump in initclocks().
There is probably equivalent code in drm(4) making the same
assumption.
Relatedly, in cpu_relax() we increment jiffies if the kernel is
cold:
sys/dev/pci/drm/include/linux/processor.h
12 static inline void
13 cpu_relax(void)
14 {
15 CPU_BUSY_CYCLE();
16 if (cold) {
17 delay(tick);
18 jiffies++;
19 }
20 }
