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

[Benjamin Berg]

Hi,

On Thu, 2024-09-19 at 16:37 +0200, Benjamin Beichler wrote:
> 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.

And now here I am proposing another form of "malicious" userspace
detection …

> 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).

Yeah, that does not really sound like something we would want (and it
will also not help with performance with time-travel=ext).

Looking at the old discussion, it doesn't seem that Johannes was
against the idea of doing the time insertion only in more specific
scenarios. So, we "just" need a reasonably elegant solution.

If we accept writing a list of syscalls, then maybe we could just do it
within handle_syscall and do a um_udelay(1) for any syscall that takes
a timeout parameter (select, pselect6, poll, ...)? It is going to be a
pretty long list, but could still be reasonable.

One neat side effect is that if reading time does not actually cost
time, then we could implement clock_gettime in the VDSO.

Benjamin