[PATCH] um: insert scheduler ticks when userspace does not yield

[Benjamin Beichler]

Am 19.09.2024 um 16:22 schrieb Benjamin Berg:
>> Could this also eliminate/address the busy-loop hack in timer_read in
>> time.c?
> Hmm, I was considering changing the other hack in handle_syscall to
> also use this approach.
>
> But, I don't think the timer_read hack can be removed. In the case of
> userspace reading the time, it should not see the difference of the
> sched_clock. So even though the process would start use CPU time, the
> realtime clock should not change and python would continue to busyloop.
> the actual clock ticks.

Okay, I think you are right.

Nonetheless, my proposal would be anyway to shift the advance of the 
realtime clock only into user space systemcalls and not every function 
in the kernel, that reads the timer.

I made ages ago the mediocre proposal to check the syscall number here, 
to detect "malicious" user space programs doing busy loops.

For "clean" semantics of a simulative execution of the kernel, it feels 
erroneous to advance time even if this value is only read once.

In my experiments timer_read was called much more often than I 
anticipated (e.g., filesystem code).