Mouse wrote: > Agreed. ITIMER_REAL in the form I've been arguing for is of little > help to a process that wants timer ticks separated by a hard minimum > interval as seen by the signal handler. At least when using > it_interval to get repeated signals. > > But then, so is every other ITIMER_REAL I've ever used.
Maybe a possible answer/hack is a new timer like ITIMER_MOSTLY_REAL or ITIMER_TICK or some variation thereof, which doesn't change existing semantics for the current timers? The original discussion that lead to this was timekeeping on a simh vax running on amd64 where both had HZ=100. We also have archs like pmax that use HZ=256 and alpha that use HZ=1024. Timekeeping isn't going to work well on those where the requested HZ is greater than the host HZ. Similarly, the discussions on this thread aren't going to help a 100 HZ simh vax keep time any better if run on a shark with HZ=64(!). qemu uses ppoll() which is implemented with pollts() to do emulated timers, so that doesn't help here. I don't know what simh uses, nor any of the other emulators. I have a grotty hack that attempted to spin if the requested timeout was less than a tick based on what DragonflyBSD does. It mostly worked for simple tests but I haven't tested it seriously. It's at https://www.NetBSD.org/~simonb/pollfixhack.diff . This is potentially another direction until we get a pure tickless kernel... Cheers, Simon.
