Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/57718; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero
Date: Wed, 22 Nov 2023 16:36:21 +0700

     Date:        Wed, 22 Nov 2023 08:05:01 +0000 (UTC)
     From:        mlelstv%serpens.de@localhost (Michael van Elst)
     Message-ID:  <20231122080501.548ED1A9239%mollari.NetBSD.org@localhost>
 
   |  While there are places that work around the issue, there are others
   |  that do not. Auditing the code and cleaning up needs to happen with
   |  or without a change to mstohz().
 
 Oh, absolutely, I agree.   The earlier message was just pointing out
 that there must have been some people who were already aware of this
 as a problem.   (I have found a couple more workarounds I didn't
 notice earlier).
 
 Certainly nothing which calls mstohz() appears to want a 0 result though,
 so:
 
   |  After that we should remove the assertion that waiting for 0 ticks is
   |  illegal. This case should be treated like the event had already occured.
 
 would largely be for new code (or that which I have not yet seen).
 Everything I have looked at so far wants there to be some delay, not nothing.
 But I am only getting started - maybe 10% through the list so far...
 
 From what I have seen so far, the uses (including indirect ones via other
 functions and macros) and so far things look to be all over the place.
 In the following, the assumption is that 0 is never wanted, regardless of
 what would otherwise happen...
 
 For some, rounding down looks to be best (for things like polling, it
 is generally better to poll slightly faster than expected, than slower,
 to avoid missing events) - for others rounding up would be better (for
 timeouts, and "wait for hardware" delays, waiting slightly longer
 rather than slightly shorter is better), and for quite a lot, it simply
 doesn't matter - that includes the ones that simply use a large (multi-second)
 timeout, where +/- 1 tick is irrelevant, but others which much smaller
 values, which are entirely arbitrary (like the schedueller intervals,
 where all that matters is that there are (non-zero) values, the actual
 sizes might affect performance, but they're tunable, so something can be
 selected which works, whichever way the calculation rounds).
 
 I am making a record of what I am seeing, which I will append here when it
 is done, so people can look at the ones they're familiar with, and determine
 better than I can, whether my assumptions are correct or not.
 
 kre