Scott Cheloha wrote: > - A tick is a 32-bit signed integer on all platforms. If HZ=100, we > can represent at most ~248 days in ticks. This is plenty. If HZ=1000, > we now only have ~24.8 days. Some may disagree, but I don't think this > is enough.
So the question is what happens when a timeout fires early? Kernel code we control, and we can fix that. By inspection, it seems nanosleep is already non-compliant since posix says it may not return early. We'd need to add a loop or something. And review other userland interfaces to timeouts. > A compromise is to make ticks a long. kettenis mentioned this > possibility in a commit [1] some time back. This would allow 64-bit > platforms to raise HZ without crippling timeout ranges. But then you > have ticks of different sizes on different platforms, which could be a > headache, I imagine. If we have learned anything from off_t and time_t, it's that such splits cause a lot of ongoing difficulty. > - How does an OpenBSD guest on vmd(8) behave when HZ=1000? Multiple such > guests on vmd(8)? Such guests on other hypervisors? If the host is HZ=1000 and the guest is HZ=100, time keeping works much better. :) > And then... can we reduce wakeup latency in general without raising HZ? Other > systems (e.g. DFly) have better wakeup latencies and still have HZ=100. What > are they doing? Can we borrow it? Ideally, yes. The lapic can be programmed to fire one shot with a much shorter duration, but this quickly gets complicated with coalescing, etc.
