Re: [PATCH RFC 10/11] um: Delay timer_read only in possible busy loops in TT-mode

Johannes Berg
2023-11-06T20:51:43Z

On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> This slows down external TT-mode as more simulation roundtrips are
> required, and it unnecessarily affects the determinism and accuracy of
> the simulation.

I still don't think this is really true, it doesn't really affect
determinism? It makes it ... different, sure, but not non-deterministic?

> +static const int suspicious_busy_loop_syscalls[] = {
> + 36, //sys_getitimer
> + 96, //sys_gettimeofday
> + 201, //sys_time
> + 224, //sys_timer_gettime
> + 228, //sys_clock_gettime
> + 287, //sys_timerfd_gettime
> +};

That's kind of awful. Surely we can use __NR_timer_gettime etc. here at
least?

> +static bool suspicious_busy_loop(void)
> +{
> + int i;
> + int syscall = syscall_get_nr(current, task_pt_regs(current));
> +
> + for (i = 0; i < ARRAY_SIZE(suspicious_busy_loop_syscalls); i++) {
> + if (suspicious_busy_loop_syscalls[i] == syscall)
> + return true;
> + }

Might also be faster to have a bitmap? But ... also kind of awkward I
guess.

I dunno. I'm not even sure what you're trying to achieve - apart from
"determinism" which seems odd or even wrong, and speed, which is
probably easier done with a better free-until and the shared memory
calendar we have been working on.

johannes