> Date: Tue, 1 Sep 2020 11:05:26 -0500 > From: Scott Cheloha <scottchel...@gmail.com> > > Hi, > > At boot, if we don't know the lapic frequency offhand we compute it by > waiting for a known clock (the i8254) with a known frequency to cycle > a few times. > > Currently we cycle hz times. This doesn't make sense. There is > little to no benefit to waiting additional cycles if your kernel is > compiled with a larger HZ. Mostly it just makes the calibration take > longer. > > Consider the common HZ=1000 case. What is the benefit of looping an > additional 900 times? The point of diminishing returns is well under > 1000 loops. > > 20-50 loops is probably sufficient to limit our error, but I don't > want to break anything so let's use 100, like we do on default > kernels. > > ok?
Sorry, but this makes no sense to me. The current code waits for 1 second regarless of what HZ is. And I expect that the accuracy of the measurement depends on the total number elapsed time, so I expect a less acurate results if you only wait 100 cycles at HZ=1000 (which is 0.1 second). > Index: lapic.c > =================================================================== > RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v > retrieving revision 1.55 > diff -u -p -r1.55 lapic.c > --- lapic.c 3 Aug 2019 14:57:51 -0000 1.55 > +++ lapic.c 1 Sep 2020 15:58:41 -0000 > @@ -509,15 +509,15 @@ lapic_calibrate_timer(struct cpu_info *c > > startapic = lapic_gettick(); > > - /* wait the next hz cycles */ > - for (i = 0; i < hz; i++) > + /* wait a few cycles */ > + for (i = 0; i < 100; i++) > wait_next_cycle(); > > endapic = lapic_gettick(); > > intr_restore(s); > > - dtick = hz * rtclock_tval; > + dtick = 100 * rtclock_tval; > dapic = startapic-endapic; > > /* > >
