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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
