[PATCH RFC 09/11] um: Delay timer_read in time travel mode only after consecutive reads

[Johannes Berg]

On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> Given the presence of numerous timer_read calls in well-behaved code
> within the kernel and userspace, particularly those that do not employ
> busy loops, we introduce a delay in reading the timer only after several
> consecutive attempts (currently set at 10).
> 
> Unfortunately, it is challenging to differentiate between various
> callers and pinpoint specific misbehaving code, so this is only a
> mediocre heuristic.

Could use with some more comments in the code I guess. :)

Generally I'd say what we have now isn't a _problem_, but in a sense if
you implement infinite CPU speed ... why does reading the time take
time? Not that I think it's _wrong_, and arguably you always should've
expected reading time to take time, but ...


Arguably though this should be squashed with the next patch since you
restrict it there?

johannes