Re: Kernel MS Precision

Benjamin Walsh <benjamin.walsh@...>

On Thu, Mar 23, 2017 at 03:40:42PM +0000, Rosen, Michael R wrote:
However, having timeouts as int32_t instead of uint32_t, there is nothing
preventing us from using negative values to represent other units if we want
to, in a backwards-compatible way. The only negative value currently is
K_FOREVER (0xffffffff). So, if we wanted to implement better granularity, we
could allow for a higher-rate system clock and add macros to the API like,

#define US_TIMEOUT(us) \
(int32_t)((((uint32_t)(us)) & 0x3fffffff) | 0x80000000)
// ^^^^^^^^^^^^^^^^^^^^^^^^
// keep the two upper bits as control bits just in
// case '10' would mean 'microseconds', '11' could
// mean something else

rc = sem_take(&my_sem, US_TIMEOUT(500));

and have the kernel timeout code decode this as the number of ticks
corresponding to 500us.

This is of course not implemented, but should be somewhat easy to do.
While Im not sure Im 100% convinced, having negative numbers just be
the number in ticks as it was in the old API should be fine. Im
curious though why you went for ns when most system wouldn't be able
to handle sub microsecond ticks; is there actually support for
sub-tick timeouts/timers?
ns or us, you still needed 64-bit timeouts for either, which ended up
being the major concern. 64-bit math can be costly: we've seen stack
usage increase of 80 bytes on some architectures. Also, I don't think
2000s is enough for a maximum timeout, with us resolution and signed

Though at the same time, if users are expected to use the macros, why
change it away from ticks at all? And if they aren't, why have the
K_MSEC macro at all? If ticks are the most precise unit you can use
I think ms is the unit most users will use, and that one does not always
need a macro.

I don't remember why we added K_MSEC(), maybe to round up the API
with K_SECONDS, etc.

The users can decide to use the macros or not.

Do you prefer





Which one is less confusing or error-prone ?



is perfectly readable.

for timers/timeouts and ticks are user configurable, why hold the API
rigid to ms? Sorry I didn't jump on this topic when you were doing the
redesign or I would have contributed this perspective then :(
Because we wanted to go to a tickless kernel, so we wanted to have the
API use common time units instead of ticks.

This was covered in the unified kernel RFC. You can search the mailing
list of still find an early version here:

It's still pretty accurate, but it's missing the ms timeouts discussion,
since we decided not to use gerrit to handle RFCs after this was
published, and thus never updated.

My take on this is that there is a way forward that is
backwards-compatible with the current API. It should probably be
configurable, since the timeout code will take hit to handle the two
time units.

That work can be turned into a Jira and prioritized if deemed important
enough, and it seems it is, for you at least, which means that probably
other people will hit the same issue.


Join to automatically receive all group messages.