Scott Cheloha <[email protected]> wrote: > On Sat, Dec 10, 2022 at 09:33:55AM -0700, Theo de Raadt wrote: > > Mark Kettenis <[email protected]> wrote: > > > > > So really the question is whether we should register the "tick" > > > timecounter if we also provide the "stick" or "sys_tick" timecounter. > > > > > > Personaly I think the code we currently have is fine. If you make the > > > sconscious decision to use "tick" on a system that provides "stick" or > > > "sys_tick" you'd better make the conscious decision not to use the CPU > > > frequency scaling stuff. > > > > Right. Is it really any different than choosing a clock with known or > > unknown > > quirks on an x86 machine: > > > > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > > I think this situation is different from the one on i386/amd64. > > When we offer a timecounter to the end user, we're saying (1) this > clock is monotonic, and (2) this clock counts at a fixed frequency. > The quality number then gives you a hint about which clock is best. > > So, yes, some of those x86 clocks are slow compared with the TSC, but > they still count time correctly.
Really. Are you willing to put money on that? That on x86, none of the clocks are variant anymore, especially after a resume? How much money. Anyone else want to put money on it? We'd be talking a 1 year long bet to discover a mistake...
