| Message ID | 20231103-bb-timetravel-patches-v1-9-e2c68efcf664@uni-rostock.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Several Time Travel Mode Enhancements | expand |
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
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c index f1b2ca45994d..f76237cfc1ea 100644 --- a/arch/um/kernel/time.c +++ b/arch/um/kernel/time.c @@ -723,6 +723,9 @@ static irqreturn_t um_timer(int irq, void *dev) static u64 timer_read(struct clocksource *cs) { + static unsigned long long last_timer_read; + static int consecutive_calls_at_same_time; + if (time_travel_mode != TT_MODE_OFF) { /* * We make reading the timer cost a bit so that we don't get @@ -736,8 +739,14 @@ static u64 timer_read(struct clocksource *cs) * "what do I do next" and onstack event we use to know when * to return from time_travel_update_time(). */ + if (last_timer_read != time_travel_time) { + last_timer_read = time_travel_time; + consecutive_calls_at_same_time = 0; + } else { + consecutive_calls_at_same_time++; + } if (!irqs_disabled() && !in_interrupt() && !in_softirq() && - !time_travel_ext_waiting) + !time_travel_ext_waiting && consecutive_calls_at_same_time > 10) time_travel_update_time(time_travel_time + TIMER_MULTIPLIER, false);
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. Signed-off-by: Benjamin Beichler <benjamin.beichler@uni-rostock.de> --- arch/um/kernel/time.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)